[Cosmo-dev] atom media creation/update

Brian Moseley bcm at osafoundation.org
Mon Jun 11 10:35:20 PDT 2007

in the current atom implementation, clients create and update
resources by POSTing and PUTting atom entries that contain various
representations of the resources (eim-json or eimml content in the
case of items, plain text content for preferences, xml extension
elements in the entry document itself for subscriptions).

however, the server often ignores the metadata in the entry documents
- title, created and updated timestamps etc. for items, this data is
redundant with what's specified in the eim data in the entry's
content, and the content is actually what's used to change the state
of the item in the server. all of the entry data other than the
content is basically just thrown away. subscriptions and preferences
use the entry's title (maps to subscription display name and
preference key), but all the other metadata is ignored.

for our purpose, the atom entry document is useful on read operations,
because the metadata includes links to alternate representations of
the resource, but there's no need for it at all on write operations.
it wastes bandwidth and adds unneeded complexity to the client.

i propose that instead we could use APP's facility for creating and
updating media directly. let's take subscriptions as an example. we
could define a representation that includes the subscription's display
name, ticket key and collection uuid and then POST just that
representation, using its media type, to the subscribed collection.
the server would create the subscription in the database and send back
what atom calls a "media link entry". it's an entry with no content
but with a link to the media itself. the client could follow that link
to GET a representation of the subscription. the same process would be
used for updates - PUT the subscription representation directly to the
media uri. no need for the client to ever waste bandwidth sending the
extraneous entry document.

i propose that we use xhtml with simple custom microformats to
represent subscriptions and preferences. this data is easily parsed by
the browser for use in our ui, and it makes debugging easier, since i
can jump into a browser, GET a subscription and see it rendered,
rather than having to save it as a file to disk and open it with a
text editor, which is usually what i have to do for entry documents.

we already have eim-json and eimml for representing items, so there's
no need to come up with anything new there.

comments? concerns?

More information about the cosmo-dev mailing list