By the way, that last post was in the context of a series of ongoing experiments with the Atom Publishing Protocol.
I switched back to Java (over Python) for the back-end "Atom Store" portion. Not particularly because I wanted to write more Java, but because I really wanted to use the Abdera codebase. Their progress continues to impress me and there doesn't seem to be any good reason to duplicate their hard work.
But after wasting another day fighting with Java tools, I am serious about needing a change of environments.
So here's a crazy idea: What about a "mod_atom"? I.e., an Apache httpd module that supports the basics of the Atom Publishing Protocol in much the same way that mod_dav adds DAV capabilities to the Apache web server.
Advantages: it could be fast. Fast as in written-in-C fast. Fast as in linked-into-httpd fast. Fast as in libxml/expat fast. And similarly, very memory efficient, especially considering that the footprint of httpd, which is typically already running on the server anyway, is much smaller than a Tomcat instance doing the same work. Also, it could be simple (i.e., less feature-rich) as the typical apache module development cycle tends to be slower paced. And most importantly, half of Atom Pub is really just HTTP, and nothing does HTTP better than httpd. All of the hooks are right there for the using. Admit it, APR rocks.
One more advantage: I'm in the quiet minority I think, but the whole "open source" Java thing has left me with a pretty bad feeling. A stack consisting entirely (L)GPL, Apache, and BSD licensed code makes me sleep better.
Disadvantages: security, insofar as one needs to walk carefully around third-party data in a world of buffer overflows. Memory must be managed, which a pain for those of us spoiled by GC'd runtimes, though httpd's pooled memory makes that much easier. Extensibility will be more of a challenge compared with, say, Abdera. Supporting things like GData, OpenSearch, or arbitrary extended elements will probably be outside the initial scope. (Atom Threading Extension might make the cut, though, as that's a big part of the functionality I'd be building this to get.)
A simple first pass at this would probably have only a rudimentary to store and retrieve entries to the filesystem. The persistence layer could be abstracted a bit; I could see wanting to persist to a bdb instead of flat files. While I wouldn't want to link the mysql client libs into httpd, sqllite might also be a good candidate, too. Authentication, url mappings, load balancing, proxying, and whatnot would all be handled by standard httpd modules and configurations.
Please speak up now if you can see a reason why creating a simple "Atom Store" as an Apache httpd module would be a bad idea.