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 aDELETE request to its Member URI, as specifiedin [RFC2616]. The deletion of a Media LinkEntry SHOULD result in the deletion of thecorresponding 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.
No comments:
Post a Comment