Thomas Broyer wrote:
As I already said, I'm not sure using an enclosure and an additional atom:link/@rel is "a more consistent and easy-to-understand model". I haven't had time yet to write an alternate Pace, I'll try to do it tomorrow, or at least before this week end…
I'm very keen to see your proposal. I like the idea of all types of entries referencing their content using content src. In the case of media entries that content might be an image or an audio file. In the case of regular atom entries, the content would cust point to a chunk of (x)html. They can both be handled identically.
You'd still need some kind of accept header or tag that tells you what type of data a collection will accept, but I'm thinking something more along the lines of "image/*; audio/*" and "text/html; application/xhtml+xml" rather than "media" and "entry". This would also allow for collections accepting "multipart/mixed" if they want to support POSTing a full cat blog entry in one step without requiring separate media and entry collections.
Updating entry content would just be a matter of PUTing the new data (whether html or a binary media) to the "editsrc" link (or just the content src IRI if there is no "editsrc"). Updating metadata would involve PUTing an Atom entry to the "edit" link (either leaving out the content element, or keeping it exactly as seen in the collection - I'm unsure about that).
Collection retrievals are quick because they never contain any actual content - just IRIs pointing to the content. Metadata edits are quick because they don't require updating the full content of an entry just to change its title or add a tag. I'm not sure if I've missed something, but it seems very simple and consistent to me.
Anyway, that's basically what I envisioned. I don't know if you're thinking along the same lines, but I'm curious to see what you come up with.
Regards James
