Adam T's blog: Life in the FAST lane

Thanks to everyone for your interest - it caught me by surprise! I was on vacation last week, so I'm sorry that there's been no further news until today.

What's been built so far is only a technical proof and has some severe limitations as it was hacked together quite quickly. I was always expecting to re-write it properly and some of the suggestions in the comments are helping me direct the architecture into a more open and flexible way than I had originally intended.

One particular point that I must stress is that it is not my intention to completely cover the JMS API. Simplicity of use is the key motivator; anything that requires the user to think in a JMS way instead of interacting with the files and directories is likely to be excluded from the implementation. Of course, once the source is published then anyone is free to add whatever they like.

Some features which I've not really mentioned yet but I'm planning to build are:

• JMS Headers. Should map nicely into extended filesystem attributes. This may also enable the equivalent of message selectors.
• Pluggable JMS providers. My initial plan was to support SunMQ and OpenMQ. Clearly, there's demand for other providers too so the architecture will be open to this. However, successful implementation of, say, ActiveMQ depends on the richness of the APIs outside the JMS specification (e.g. fetching a list of queue names, creating durable queues).

Some things don't seem to map very well to the filesystem metaphor:

• Transactions. I don't currently see a "clean" way to implement them that would be natural to a filesystem user (although I'm open to suggestions).
• Request-reply. Done in the traditional JMS way, a temporary queue is generated automatically during the request and the reply is read from this queue. Synchronous messaging like this doesn't fit a filsystem model. However, we could probably emulate this by setting the JMSReplyTo header when creating the file (extended FS attribute). The reply would go onto a temporary queue with that name and the client would simply poll for it asynchronously.
• Queues vs Topics. This is an important one. When reading from a destination, it doesn't really matter if it's a queue or topic. However, when creating a new destination you would have to specify the type. How can we do this, when at best you have the "mkdir" command?

One other issue which came up is in-place editing of files. There's no reason for a user not to open a file in their favourite editor. There are a number of side-effects of this. For instance, the editor will commonly create a temporary file in the same directory for undo/recovery purposes. Obviously we don't want these transmitted to the remote server. Nor do we want the messages to be sent each time we hit the save button!

Hopefully you can see that some thought is being put into this... I'll keep you posted as things progress.

p.s. Keep coming up with project name suggestions!