stockquote command

I just committed a new "stockquote" command, which can take any number of ticker symbols -- it was designed to show off using the new response mechanism to send back multiple responses to the client. It is also a decent example of using the "active" status of a command.

This will also be a good candidate for a possible persistence mechanism -- for instance, you could save a bunch of ticker symbols and just ask the bot instance to give you quotes for all of them without needing to enter them. But, that's an open question: should the SLIMBot framework provide such persistence, or should a developer be expected to roll their own?

I do think SLIMBot should probably have some kind of application and session-level caching mechanism, but persistence is probably outside the scope. But, if that's true, how would a developer do something like tell their code what datasource to use for a query when interfacing their persistence mechanism inside a SLIMBot command? Would they be expected to build some kind of facade for use specifically in SLIMBot? Would that be something in the instance-level config (another topic not yet addressed)?

New Response Mechanism

Last night I committed some non-trivial changes to the way the commands are built. The biggest one is that instead of the command returning a string in the doCommand method, you now use an internal method called RESPONSE. This allows for a single command to return more than one response and/or allows the command to send responses to someone other than the person originating the request (though, that is subject, of course, to the nature of the IM service you are using -- most don't allow sending of messages to people not on a buddy list, so the BuddyID associated with the SLIMBot instance would need to be on someone's buddy list for that to work in most cases).

As a result of that, the command API for developers of commands can now be much richer and yet simpler because an instance of a command is now somewhat stateful -- and thus aware of its context (thus, no longer needing to pass the raw CFEVENT into each doCommand call).

I could make it so that you don't even need to pass the input to the command and instead make a getInput method in the baseCommand, but I think that might actually be less simple for people making the most of commands, for whom it might be handy to have the command input available directly in the arguments of the doCommand method. Thoughts on that are welcomed, but since RIAForge isn't letting up do a "release" (And the zip from SVN links isn't active on SLIMBot either!), I doubt anyone out there is actually involved with the code yet.

If a blog post falls in the woods, and nobody is there to read it, does it... you get the idea ;)

BlogCFC was created by Raymond Camden. This blog is running version 5.5.006. | Protected by Akismet | Blog with WordPress