DELETE on AtomPub media resource

I read somewhere that deleting an AtomPub media resource associated with a feed item (using HTTP DELETE) should also delete the feed item. It turns out that the eXist AtomPub implementation does not support this, claiming (erroneously) that the resource does not exist.

Examining the AtomPub spec provides little support (though on first reading I actually thought this did support what I want to do):

To delete a Member Resource, a client sends a 

DELETE request to its Member URI, as specified 

in [RFC2616].  The deletion of a Media Link

Entry SHOULD result in the deletion of the 

corresponding Media Resource.

-- RFC 5023, section 9.4

This is unfortunate for Shuffl, as I had been hoping to not get too bogged down in feed items vs resources. Now I might need to include a feed item URI along with card data if I'm to be able to delete the card data. Or maybe I'll just delete the feed and recreate it without the missing data?

More generally, I am beginning to wonder if AtomPub was the best choice for persisting Shuffl data. I estimate the complexities of dealing with AtomPub have cost me a week or so in slippage, and that I would be better off with WebDAV. I'll stick with it for now, but I'm thinking about a plug-in framework for Shuffl back-end support so I can support alternative protocols.

eXist and Jetty configuration

My initial experiments to get eXist installed and running as an AtomPub server went very smoothly.

But I've just spent a day thrashing around with the server configuration, trying to get it to serve static files from the Shuffl project test directory so that I can run tests more easily, without falling foul of the Javascript "same origin" restriction. This has been complicated by a number of factors:

• Jetty is natively configured by Java object dependency injection, for which XML configuration files are a shim interface
• the Jetty documentation isn't very approachable, especially as the XML configuration sections don't actually tell you how to configure the server - for that, you have to dig into the various servlet classes to understand the values that need to be injected
• some configuration options can alternatively be applied through the servlet container configuration (web.xml), which is a completely different format
• the eXist installation runs a specially tailored configuration of Jetty that doesn't immediately make it easy to find the configuration options
• default security settings in Jetty do not permit following symbolic links when serving static files

Most of these are not necessarily bad things, but in combination they create a system whose configuration is about as user-friendly as a cornered rat. For me, the breakthrough came when I found a line in the eXist documentation "The Jetty configuration can be found in tools/jetty/etc/jetty.xml" (http://exist-db.org/deployment.html, section 3). This is relative to the eXist installation directory.

Editing this file, I can change (almost the last line in the file):

<Set class="org.mortbay.util.FileResource" name="checkAliases" type="boolean">true</Set>

to

<Set class="org.mortbay.util.FileResource" name="checkAliases" type="boolean">false</Set>

Now I can create a symbolic link shuffl in ${EXIST_HOME}/webapp, linking to my shuffl project directory, and by pointing my browser at http://localhost:8080/exist/shuffl/ I can browse my project directories and run the test files via eXist. Phew!

Shuffl back-end selected

The initial back-end software for Shuffl has been selected and checked out. I'm planning to use AtomPub for the back-end protocol, and eXist as the back-end database. Rationale for the choice can be seen at http://code.google.com/p/shuffl/wiki/BackendSystemsSurvey. I've installed eXist (piece of cake!) and run a series of tests against the out-of-box installation to demonstrate the identified capabilities are all present. See http://code.google.com/p/shuffl/source/browse/#svn/trunk/spike.