WEBUI_MODULE brainstorming

If you have created a 3rd party module you'd like other people to use, post it here
Marebone
The Team
Posts: 175
Joined: Sun Sep 04, 2011 7:38 am
antispam: Rimor

Re: WEBUI_MODULE brainstorming

Postby Marebone » Sun Dec 11, 2011 8:50 am

With that kind of mechanism the API could be extended also for registration and authentication. Say, your org could have a private forum; When user registers to the forum the forum software could send the activation message (normally sent by email) via bot API to the player in-game.
Whenever user wants to log in to the forum he could access it using his toon name and password given with the !setpass.
User avatar
Team_Eli
Member
Posts: 259
Joined: Wed Dec 02, 2009 7:02 am

Re: WEBUI_MODULE brainstorming

Postby Team_Eli » Sun Dec 11, 2011 11:37 am

Uh-huh... uh-huh.. yeah... *drool, slobber*

Keep wetting my appetite guys...

I've taken 'Webshop' on both Servers... for once, I'm
ahead on the name-game...
:)

I can see it now... Myshop, with a Web front-end.
Just throw stuff in through drag-n-drop on the bot
then use the web-page to move it around, price it,
etc...

Lots of lovely icons, and access to the item database...
Oh this is going to be fun.

btw: Where can I get this magical goodness you call
WEBUI? Somewhere in the SVN?

Eli...
Image

In case your wondering.. I'm the one with the beard...
Marebone
The Team
Posts: 175
Joined: Sun Sep 04, 2011 7:38 am
antispam: Rimor

Re: WEBUI_MODULE brainstorming

Postby Marebone » Sun Dec 11, 2011 6:52 pm

Heh, well, I guess what I wanted to say is that the API could be used by any number of clients (like Eli's web shop for instance). As such this web based admin UI would be only one of them.

What about if some module developer would like to extend the API so that it would support also some module specific API requests?
Instead of adding his own code lines to the API_MODULE, could the developer have the API requests routed through his own module somehow? Kinda like, encapsulating request handling to within modules instead of the API_MODULE handling all requests by itself.
Tyrence
Posts: 1959
Joined: Sat Jan 09, 2010 1:32 am

Re: WEBUI_MODULE brainstorming

Postby Tyrence » Sun Dec 11, 2011 8:05 pm

Hmmmm, I like this idea.

We could let modules register API commands the same way they register normal commands. For instance, if you wanted to be able to check the status of the city cloak both from in game and through the API:

Code: Select all

Command::register($MODULE_NAME, "", "cloak.php", "cloak", "guild", "Shows the status of the city cloak");
APICommand::register($MODULE_NAME, "", "cloak_api.php", "cloak", "guild", "Shows the status of the city cloak");

Something like that would work I think... If we then let anyone set an API password, then we could still use the same security framework and access levels for API commands.

On the other hand, maybe it would be worthwhile to figure out a way to allow any command to be invoked through the API. Actually, this can be done easily. The problem is formatting the response (or rather, removing the AO formatting from the response).
"Those who expect to reap the blessings of freedom, must, like men, undergo the fatigues of supporting it." — Thomas Paine
"Nearly all men stand adversity, but if you want to test a man's character, give him power." — Abraham Lincoln
Budabot Releases and Downloads: https://github.com/Budabot/Budabot/releases
User avatar
Team_Eli
Member
Posts: 259
Joined: Wed Dec 02, 2009 7:02 am

Re: WEBUI_MODULE brainstorming

Postby Team_Eli » Sun Dec 11, 2011 9:05 pm

Eeesh.. big question... lots of ways to answer. :)

Yes, I suppose it could be done.. but why would you?
The webserver would have access to the database via php,
far easier I would think (for most commands) to let it get
the data directly and process it for display...

You -could- set it up so that anything with ! as the first char
coming from the webserver was passed as a command, and
processed in budabot as normal...

then add a new msg type 'web'... so Buda knows to pass the
result back to the web api... but you'd still have to write code
on the web end to take out all the formatting, and display it
as a web page...

This pre-supposes of course, that the webserver and budabot
are running on the same host/computer... if you want to give
people the flexibility of running the two on separate hosts, then
yes, you have to deal with the extra complexity that would
involve...

All decisions way, way above my pay-grade... I'll let Ty and
others decide. :)

Eli...
Image

In case your wondering.. I'm the one with the beard...
nagahiro
Member
Posts: 41
Joined: Mon Oct 03, 2011 6:42 pm
antispam: Rimor

Re: WEBUI_MODULE brainstorming

Postby nagahiro » Mon Dec 12, 2011 4:22 am

Tyrence wrote:Hmmmm, I like this idea.

We could let modules register API commands the same way they register normal commands. For instance, if you wanted to be able to check the status of the city cloak both from in game and through the API:

Code: Select all

Command::register($MODULE_NAME, "", "cloak.php", "cloak", "guild", "Shows the status of the city cloak");
APICommand::register($MODULE_NAME, "", "cloak_api.php", "cloak", "guild", "Shows the status of the city cloak");

Something like that would work I think... If we then let anyone set an API password, then we could still use the same security framework and access levels for API commands.

On the other hand, maybe it would be worthwhile to figure out a way to allow any command to be invoked through the API. Actually, this can be done easily. The problem is formatting the response (or rather, removing the AO formatting from the response).


Although I initially wanted to work towards an API that could invoke any command, I like the idea of adding an APICommand Event a lot. Most importantly I think that this adds an additional layer of security, because certain commands such as !admin add could be blocked by just not having an API event for them.
Marebone
The Team
Posts: 175
Joined: Sun Sep 04, 2011 7:38 am
antispam: Rimor

Re: WEBUI_MODULE brainstorming

Postby Marebone » Mon Dec 12, 2011 4:26 am

Team_Eli wrote:This pre-supposes of course, that the webserver and budabot
are running on the same host/computer... if you want to give
people the flexibility of running the two on separate hosts, then
yes, you have to deal with the extra complexity that would
involve...

At least in my org's case we have webserver running on one host, bots on another, and backup bots on third. Exposing one database to public internet might have some security issues, I'm not clear though what...
The bots are also probably using sqlite so exposing that might prove difficult even.

Tyrence wrote:On the other hand, maybe it would be worthwhile to figure out a way to allow any command to be invoked through the API. Actually, this can be done easily.

Well, that separate register call could provide more flexibility to provide options necessary for the API (whatever that would be).
But, on the other hand, handling of the API command as a normal command would be less hassle for module developer since there is no need for extra calls for registering.

Tyrence wrote:The problem is formatting the response (or rather, removing the AO formatting from the response).

Or is it? How about if it would just return what ever the module sends with Budabot::send(). If module sends JSON, then JSON is returned through the API. If the module sends AOML then that is what is received through the API.
If the output should be something else than AOML then the module can render its output differently. Just tell the module where the response should be sent; some player, org chat or API. The module could then decide what is the correct format for the response.

This would have the added bonus, that all existing commands of all modules could be exposed through the API with ease, no extra coding, within modules, would be necessary, the output's format just might not be very handy for web clients. Not at first at least, until module developers would start to add different formats to their modules.
nagahiro
Member
Posts: 41
Joined: Mon Oct 03, 2011 6:42 pm
antispam: Rimor

Re: WEBUI_MODULE brainstorming

Postby nagahiro » Mon Dec 12, 2011 4:41 am

Marebone wrote:
Team_Eli wrote:This pre-supposes of course, that the webserver and budabot
are running on the same host/computer... if you want to give
people the flexibility of running the two on separate hosts, then
yes, you have to deal with the extra complexity that would
involve...

At least in my org's case we have webserver running on one host, bots on another, and backup bots on third. Exposing one database to public internet might have some security issues, I'm not clear though what...
The bots are also probably using sqlite so exposing that might prove difficult even.


The database isn't really exposed since all access/authentication is handled through PHP which obscures the access routines. In fact, what Eli is suggesting was my initial idea as well, the problem here is that a lot of information isn't committed to the database immediately, which is why Tyrence stepped in to develop an API framework which can get relevant data from the PHP server's cache (coincidentally it is also the reason I now have 3 500-silly-some-page books flying around my house).

Marebone wrote:This would have the added bonus, that all existing commands of all modules could be exposed through the API with ease, no extra coding, within modules, would be necessary, the output's format just might not be very handy for web clients. Not at first at least, until module developers would start to add different formats to their modules.

Having all modules accessible is kind of a catch 22 in my mind (see my last post)... As far as rendering output is concerned, I think this could be done through JSON/AJAX but I definitely do not know enough about either to get this to happen any time soon.
Tyrence
Posts: 1959
Joined: Sat Jan 09, 2010 1:32 am

Re: WEBUI_MODULE brainstorming

Postby Tyrence » Mon Dec 12, 2011 5:12 am

@Eli, having a web server connect to the bot's database directly is fine IF AND ONLY IF you only care to display the data. If you want to change it, you cannot just change it in the database because the bot caches a lot of things in memory. Additionally, if you only connect to the database you can't do things like restart the bot, kick someone from the private channel, etc. So in my mind, this is not an option and we are forced to connect to the bot through the API.

Marebone wrote:Or is it? How about if it would just return what ever the module sends with Budabot::send(). If module sends JSON, then JSON is returned through the API. If the module sends AOML then that is what is received through the API.
If the output should be something else than AOML then the module can render its output differently. Just tell the module where the response should be sent; some player, org chat or API. The module could then decide what is the correct format for the response.

This would have the added bonus, that all existing commands of all modules could be exposed through the API with ease, no extra coding, within modules, would be necessary, the output's format just might not be very handy for web clients. Not at first at least, until module developers would start to add different formats to their modules.

So let me take your idea and modify just a tiny bit. I don't think passing AOML to the API is going to be beneficial because it's too broken to be shown without modifcation as HTML, and it's too ugly to be parsed effectively imo. So what if we came up with some way for a module developer to declare a command as JSON-capable. Then all JSON-capable commands would be exposed to the API (and only those commands). And this addresses Nagahiro's concern that we may not want some commands accessible by the API at all.
"Those who expect to reap the blessings of freedom, must, like men, undergo the fatigues of supporting it." — Thomas Paine
"Nearly all men stand adversity, but if you want to test a man's character, give him power." — Abraham Lincoln
Budabot Releases and Downloads: https://github.com/Budabot/Budabot/releases
Marebone
The Team
Posts: 175
Joined: Sun Sep 04, 2011 7:38 am
antispam: Rimor

Re: WEBUI_MODULE brainstorming

Postby Marebone » Mon Dec 12, 2011 6:12 pm

nagahiro wrote:Having all modules accessible is kind of a catch 22 in my mind (see my last post)... As far as rendering output is concerned, I think this could be done through JSON/AJAX but I definitely do not know enough about either to get this to happen any time soon.

Humm, I agree as well, it might have exposed stuff that might not wise to expose in the first place.

About JSON, here is a php-json crash course:
http://fi.php.net/manual/en/function.json-decode.php <-- parser
http://fi.php.net/manual/en/function.json-encode.php <-- writer

Those functions provide a way to serialize php's data structures to a string and from string back to a data structure.
When the data is in a string format, it is trivial to shovel it thorough a socket to another host, or save it to a file or as a blob in a database or whatever you want to do with it.

AJAX? errhhmm... you can throw that out of the window, you will not need it, unless your going to code with Javascript. While JSON is used a lot with AJAX (or so I've heard), JSON is not in way dependent of AJAX, it is not even restricted to Javascript. Since you can parse & write it at least with PHP, Ruby and C++ Qt, most likely with other languages as well.

Tyrence wrote:So let me take your idea and modify just a tiny bit. I don't think passing AOML to the API is going to be beneficial because it's too broken to be shown without modifcation as HTML, and it's too ugly to be parsed effectively imo. So what if we came up with some way for a module developer to declare a command as JSON-capable. Then all JSON-capable commands would be exposed to the API (and only those commands). And this addresses Nagahiro's concern that we may not want some commands accessible by the API at all.

Well, the api command registering you posted above would work for this, right?
Do you need a separate class APICommand for this? Or could you use the normal Command-class, just replace the "guild"-channel with, say "api"?

Return to “Modules”

Who is online

Users browsing this forum: No registered users and 1 guest