Directions for Action Messenger
Posted by Trejkaz Mon, 22 May 2006 12:16:36 GMT
Well, the first highly experimental release of Action Messenger experienced a small amount of success, and a couple of people spotted some bugs which have been fixed in version 0.1.1.
So now that everything works for small apps, how does it grow? I do want to integrate into Typo, and the default deployment for Typo uses FastCGI. Whereas each FastCGI process is relatively long-lived, there are multiple instances, and they can’t all be logged in at once [with the same resource.]
So I have a number of options for coping with having Action Messenger work from multiple Rails instances.
Have each instance login from a different resource. This is the simplest approach, and the one which I’m currently using on this site’s Typo install: append the process ID onto the resource when logging in. The main downside to this approach is that when I add presence support in, users who have added the bot would see all its multiple resources logged in at once. Whereas this would start out fairly small (I use 5 instances on my Typo) for larger, more popular sites, you might end up with a few dozen bots online at the same time.
Have one instance of Rails nominate it as the master, and start a DRb server on a background thread. The other instances would connect to the master when they need to send a message. This would be the simplest approach for the end user, but seems difficult to implement. Which server becomes the master? Perhaps an instance simply tries to open a socket to the server, and if it fails, it tries to open a socket as the server. In this fashion, there is always only one instance online, and when that instance goes offline (e.g. the process crashes) another one would pick it up.
Have the Rails app spawn a separate process to handle the server side of things, but otherwise do things exactly as #2.
Use something such as BackgrounDRb to run the bot as one thread of a much more flexible server. This approach is probably the most useful as things other than a Jabber bot might be run in this server, although at the moment I’m not sure what.
Write a simple, specialist Ruby bot, and require that bot to be started completely separately from Rails. The Rails instances would then connect to the bot whenever they need something.
At the moment, #5 is my favourite option. My main problem with this approach is – how will the bot handle receiving messages? Accessing the Rails models directly from the bot isn’t the problem, the problem is coming up with an API just as clean as the current one.