Release 0.0.3

I have cleaned up some of the code and fixed a couple bugs, so I am releasing a 0.0.3 in case anyone is out there testing.

The big TODO items to tackle are per-instance configuration that can be accessed inside the listener and some mechanism for authentication that allows for a flexible security system.

Release 0.0.2

Well, since RIAForge is having growing pains on its new server I can't upload a release file, which I think is now ready to be called 0.0.2 (not yet doing tagging in SVN given the early maturity of the code). But, let's see if I can upload it to the blog using the "enclosure"....

(UPDATE: sadly, the answer seems to be no == if you check out the main trunk of SVN [revision 5, for those keeping score, though I'll try to keep the HEAD fairly stable for now] you will get what I am calling 0.0.2)

(UPDATE TO THE UPDATE: uploading is now fixed, and release 0.0.2 is live!). Use the download link on the main project page:

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 ;)

First Code Release

The first working version of SLIMBot is now in SVN. I consider release 0.0.1, though I haven't even created a versioning system yet. If you try it out, would like to hear your experiences -- check out the questions in the README.txt file, as well as the questions that are in the TODO section of the comments in the slimbotGateway.cfc in the main directory.

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