It outlines one approach that I’ve been developing for the API in the BBC programme catalogue. One of the things I like a great deal about Rails is its URL routing and dispatch mechanism. Creating mappings from URLs to model instances makes a resource-oriented style feel very natural, which sits very well with REST.

Isn’t this a wonderfully literal interpretation of the article’s title?

After much thought, coding and discussion over the summer with #bots people, I came to the conclusion that a good architectural style for bots is, as jo puts it, “a stateful conversational interface to an aspect of the semantic web”. Querying and updating information is modeled by HTTP GET and POST respectively. The code is structured after the Model-View-Controller pattern commonly used in GUI development: the View is a represention over IRC or another messaging system, the Controller responds to messages generated by running a grammar-based parser over the user’s input, and the Model lives on the web. The bot only keeps state relevant to the conversation (e.g. which picture we are currently talking about).

To get the bot up and running, I started by creating a GET-able query system based on jena. It has a nice RDF query language that’s somewhat SQLish, and can use berkeleydb and rdbms backends. I modeled a store of queries in RDF and wrote a java servlet to run queries and return results in naive XML or RDF formats.

With this flexible backend, I was able to write a commandline version of a bot using simple HTTP requests and the Jakarta Digester to extract information from the XML. Adding a new feature is mostly a case of augmenting the parser’s grammar and adding a new query to the query store.

Here’s a sample session with the commandline version of the bot:

> find mailto:jo@abduction.org
mailto:jo@abduction.org depicted in http://www.picdiary.com/xcom/IMG_1676.jpg
> read xcom
0: http://www.picdiary.com/xcom/IMG_1674.jpg
1: http://www.picdiary.com/xcom/IMG_1676.jpg
2: http://www.picdiary.com/xcom/IMG_1677.jpg
3: http://www.picdiary.com/xcom/IMG_1678.jpg
> current file
xcom
> use 0
Using pic with uri http://www.picdiary.com/xcom/IMG_1674.jpg
> current pic

http://www.picdiary.com/xcom/IMG_1674.jpg

> depicts
mailto:edd@usefulinc.com
mailto:ben@hammersley.com
> use 1
Using pic with uri http://www.picdiary.com/xcom/IMG_1676.jpg
> depicts
mailto:jo@abduction.org

The next step is to extend the query system to allow updates and creates, and I’ll be nearly done.

Subject: [Bots] gatebot – making bots URL-addressable
From: Matt Biddulph
Date: Mon Aug 26 14:41:05 2002

I’ve put up a new experimental service that allows code to talk to IRC
bots over the web without making a direct IRC connection.

You can try it out here via a dodgy web form interface:

http://www.picdiary.com/bot/index.html

But it’s really meant as some kind of web API for access by code (e.g.
so web apps could ask the foafbot for people-related information). It
works like this:

POST to
http://www.picdiary.com/bot/servlet/GatebotServlet/some.irc.server/somebotnick
with a query of "say=what%20you%want%20to%say". The web service sends a
proxy bot onto some.irc.server and privmsgs somebotnick with what you
want to say.

You get back a simple HTML document, with a 201 Created status to
indicate the creation of a new session URL for you to read back what is
said. This session URL is given both in the HTML (for browser-based
testing) and in the HTTP Location: header. Every time you hit this URL,
it’ll give you a line-by-line dump of what have been privmsged back to
the proxy bot (obviously this will be blank if you hit the URL quickly -
if you expect an answer then poll it at some regular interval).

If nothing is said to the bot for 60 seconds, it leaves the IRC network
but the URL remains available ‘indefinitely’ (it’s kept in memory and
will die when my webserver restarts). You should also be able to say
further things to the same bot in the same session by POSTing to the
session URL with "say=whatever"

Source code (perl for the bot bits, java servlet for the web bits) is
here:
http://www.picdiary.com/~mattb/bots/gatebot-0.2.tar.gz
Apologies for any hard-coded paths or other cruftiness. The version of
Bot::BasicBot in there is slightly modified to listen on STDIN so that
the web layer can communicate with its proxy bots by spawning processes
and using STDIN/STDOUT.

There are a couple of pieces of demo client code in the tarball.
getkarma asks the infobot ‘robert’ on #pants for karma of things via a
commandline interface. There’s also an infobotkarmabot that does the
same thing but with an IRC interface.

Here’s the IRC karma bot connecting to #bots on london.rhizomatic.net:

–> robertpro (~robertpro@217.158.195.49) has joined #bots
<mattb> robertkarma test
<robertpro> robert says test has karma of 1

and the action this triggered on #gatebot (where proxy bots hang out
while they’re privmsging) on the irc network where #pants lives:

–> EUUREbot (tomcat4@pod-124.dolphin-server.co.uk) has joined #gatebot
<EUUREbot> robert said ‘test has karma of 1′

Feel free to play with this, and flame me royally if it breaks or sucks.

Cheers,
Matt.

and a later response to a followup:

On Mon, 2002-08-26 at 17:16, Mark Fowler wrote:
> Hmm. Any reason this can’t be a GET? Aside from the breaking of the
> idempotent nature of requests I mean (pah, RFCs.) It’d just be nice so
> that you can use it with Mozilla’s bookmark keywords function (where you
> can type ‘$keyword $foo’ and it looks up a url you’ve associated with
> $keyword changing ‘%s’ for a URI encoded version of $foo.)

Yeah, preserving the semantics of POST seems quite important here – this
is initiating an action, which causes the creation of a resource (both
in the sense of the URL and the process actually forked). This resource
then becomes readable in an idempotent way, its content changing as it
(hopefully) interacts with the remote bot it’s talking to.

In order to support an application such as ‘return me this information’
for bookmark-keywords purposes, I would rather a wrapper application
were used that was truly GETtable – it would make the initial POST and
poll the resulting GETtable session until it returned some useful
information. Only then would it return 200 OK and some content to the
client. A directly GETtable gatebot service would 99% of the time simply
return a blank screen to the browser because it has no way of knowing
how long to wait (if it should wait for a response at all).