WEBUI_MODULE brainstorming

If you have created a 3rd party module you'd like other people to use, post it here
User avatar
Team_Eli
Member
Posts: 259
Joined: Wed Dec 02, 2009 7:02 am

Re: WEBUI_MODULE brainstorming

Postby Team_Eli » Wed Dec 14, 2011 12:10 am

Marebone wrote:Well, at least on example comes to mind.

Our org's site at http://insanity-inc.com/ has this shoutbox (the list on the right side), if you're logged in there is also a text input field where you can write your own shout. That is just a ready made Joomla module called Turtushout (http://www.turtus.org.ua/files?func=fileinfo&id=13).


Nice page.. what do you use to make your pages, please? Got to find some friendly/simple tools
so I can start making my own...

Eli.
Image

In case your wondering.. I'm the one with the beard...
Tyrence
Posts: 1950
Joined: Sat Jan 09, 2010 1:32 am

Re: WEBUI_MODULE brainstorming

Postby Tyrence » Wed Dec 14, 2011 12:31 am

Marebone wrote:But, this could be implemented also so that when a shout is added on the site, the site could push the latest shouts through this new BUDAPI ( :D ) to our org bot. This way there would be less traffic between the site and the bot, as constant polling would not be required.

One shout contains username, title, message and timestamp.

Ok. I'm looking at the code for process_command() and I don't see a way to add first-class support for incoming objects since it expects the command to be a string.

So the one option is, we create a separate process_command() method specifically for the API module and add an additional field to APIRequest that would hold objects. When a request to invoke a command is sent through the api, this additional field holding objects would be deserialized and made available to the command that was processing the request.

The other option is more of a hack. In effect, you'd make an api-only command like this:

Code: Select all

Command::register($MODULE_NAME, "api", "incoming_shout.php", "incshout", "admin", "Relay incoming shouts to guild channel");

The code for sending it to the bot would look something like this:

Code: Select all

$complexObj = .... ;
$command = "incshout " . json_encode($complexObj);
sendRequest(new APIRequest($username, $password, $command));

And then the code on the bot would look something like this:

Code: Select all

if preg_match("/^incshout (.*)$/i", $message, $arr)) {
   $obj = json_decode($arr[1]);
   ...


I guess the big difference between the two is that in the first case, extracting the objects from the request is done for you by the bot, where as in case two, you would do it manually. But on the other hand, the second method would be a lot simpler to implement.
"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 » Wed Dec 14, 2011 1:34 am

Tyrence wrote:I guess the big difference between the two is that in the first case, extracting the objects from the request is done for you by the bot, where as in case two, you would do it manually. But on the other hand, the second method would be a lot simpler to implement.


I know I'm not adding much Ty.. but I'd much prefer to keep it simple... diving into core-code to figure out how to do
something, as opposed to seeing an example in module code, that could be modified, is perhaps more my level of under
standing... and also perhaps the level of many other module-level coders?

I guess it comes down to creating an API people can use, as against an API that people can admire for it's complexity and
cleverness... but avoid like the plague... :)

Good documentation is also going to go a long way to making this module ... not necessarily 'popular', but 'accessible', to
module coders.

And while I'm thinking about it... where does this put us viz the other bots out there... do any of them have a webapi
built in? We could win a few converts here, you know?


Eli...
Image

In case your wondering.. I'm the one with the beard...
Tyrence
Posts: 1950
Joined: Sat Jan 09, 2010 1:32 am

Re: WEBUI_MODULE brainstorming

Postby Tyrence » Wed Dec 14, 2011 4:55 am

Team_Eli wrote:I know I'm not adding much Ty.. but I'd much prefer to keep it simple

That would be my preference as well.

Team_Eli wrote:Good documentation is also going to go a long way to making this module ... not necessarily 'popular', but 'accessible', to module coders.

Yeah, I really should do more of that.

Team_Eli wrote:And while I'm thinking about it... where does this put us viz the other bots out there... do any of them have a webapi built in? We could win a few converts here, you know?

Well, maybe some who have migrated from other bots could weigh in on this, but in my opinion we were noticeably the best bot since 2.0 was released. When we released 2.2, we were by far the best bot. And now we are 2.3+, and there's not really any competition. Not to say that the other bots aren't good, but they haven't been actively developed in over a year. And no new contenders have come up. I think the people that haven't migrated won't migrate no matter how good Budabot is because of one of two reasons:
1) familiarity with their current bot
2) don't want to migrate alts, guestlist, etc
So to be honest, I don't think we would get a lot of converts because of it. But I think we would make a lot of current users happy. :)
"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
Snakebite
Site Admin
Posts: 246
Joined: Mon Nov 23, 2009 11:19 pm

Re: WEBUI_MODULE brainstorming

Postby Snakebite » Wed Dec 14, 2011 9:09 am

How hard is it to migrate alts lists and stuff?
Could we have a migration tool for those that would want to?
Marebone
The Team
Posts: 175
Joined: Sun Sep 04, 2011 7:38 am
antispam: Rimor

Re: WEBUI_MODULE brainstorming

Postby Marebone » Fri Dec 16, 2011 12:27 pm

Team_Eli wrote:Nice page.. what do you use to make your pages, please? Got to find some friendly/simple tools
so I can start making my own...

Ooops, sorry for the delay. We are using Joomla (http://www.joomla.org/) framework with a custom theme.

Tyrence wrote:So the one option is, we create a separate process_command() method specifically for the API module and add an additional field to APIRequest that would hold objects. When a request to invoke a command is sent through the api, this additional field holding objects would be deserialized and made available to the command that was processing the request.

How this would be handled in the module's code?
Tyrence
Posts: 1950
Joined: Sat Jan 09, 2010 1:32 am

Re: WEBUI_MODULE brainstorming

Postby Tyrence » Fri Dec 16, 2011 5:09 pm

Marebone wrote:How this would be handled in the module's code?

Well my thought for this was that when invoking a command through the api, the $apiRequest object would be set (the same way $db and $chatBot are made available) and they could use that to pull out whatever fields they needed.
"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 » Fri Dec 16, 2011 8:46 pm

How about if the api request object would be in the $message variable instead?
Add __toString() method to the object to keep it compatible with preg_match(). This way you could use the normal way to get the arguments, but if the module expects the arguments to be objects or arrays, then it could get em by using $message->command and $message->args[0], or some such.
Tyrence
Posts: 1950
Joined: Sat Jan 09, 2010 1:32 am

Re: WEBUI_MODULE brainstorming

Postby Tyrence » Sun Dec 18, 2011 5:58 am

I've been thinking about this the past few days. A few things....

First, I don't want to have to add api support for all the existing commands, especially since most of them can work with no modification whatsoever. So I am going to add a flag to the APIRequest class to indicate the type of request it is. Two types: simple and advanced. Simple requests will be handled as tell messages (the module handling the request will think that the request came as a tell message). Simple API Requests will not be able to include additional objects as part of their payload. Advanced API Requests will be handled as 'api' messages so commands handling these messages will need to be explicitly defined as 'api' commands (ie. enabled for the 'api' channel). Advanced API requests will also be able to add objects as part of the payload.

Anyway, @Marebone, your idea to override the __toString() method is a good idea. I didn't realize that PHP would automatically call it in instances where it needed a string. But I am a little concerned that we might be overdoing this. What I mean by that is I am on the fence about whether using the API_MODULE is the best way to implement the functionality you have with your FACEBOOK_MODULE. Because the API module is still using the built-in method for handling commands. And that method makes certain assumptions. For instance, it assumes that the message is coming from an actual player. And it assumes that it can get a charid for that player. And it assumes that the message is a string.

So we can get around this by overriding the __toString() method. And by having the client part of the FACEBOOK_MODULE use the name and password of a character that has been set up on the bot. I'm just not sure if we should do that...
"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 » Sun Dec 18, 2011 11:49 am

Actually, now that I think of it, I actually wanted to over do this a bit :twisted:

I was hoping that the API could have been used for other things than for the admin UI aswell, like:

  • Sending data to the bot from a website, like our JOOMLASHOUTS_MODULE, the one I gave as an example previously.
  • Pulling data from the bot and showing it on a website, e.g. showing who are currently online in-game, kinda same thing as the WEBCAST_MODULE does currently.
  • Bot to bot communication, say, you could share information like online list, alt lists, etc... between bots, even if the bots would not use the same database.
  • Bot to application and vice versa: like, say take Eli's multibank and AOIA, the AOIA could export CSV-data and sent it straight through the bot's API to the multibank module. AOIA could also import data from the bot so a user could also browse other banks within AOIA. No need to save the CSV into a file at any point.

I'm sure those are just an tip of an iceberg. You could do so much with an API like that.

Well, I guess all those above are possible without API, but each module developer would need to think their own solution if they wish to have such functionality. As I have had to with the JOOMLASHOUTS_MODULE, and now more recently with that FACEBOOKPAGE_MODULE I'm currently working with.

Return to “Modules”

Who is online

Users browsing this forum: No registered users and 1 guest