[Cosmo-dev] Sharing format wiki page

[Brian Moseley]

On 7/7/06, Morgen Sagen <morgen at osafoundation.org> wrote:
> Can someone familiar with both Atom and *DAV summarize the pros/cons
> of each?

atom is simpler to implement. a client needs only to speak basic http
to the server. atom publishing requires an xml parser as well, so that
the client can inspect a collection's "introspection document" (much
like a directory index). there is no notion of locking or resource
properties with atom.

caldav requires locking and has explicit provisions for sophisticated
reporting. with atom, one can formulate query strings for GET requests
that express the same parameterization as caldav reports, but the
names of query parameters and so forth are not standardized. gdata (a
specialization of atom) standardizes a small subset of the caldav
report options.

atom and webdav are not aware/don't care about the specific types of
content they are pushing around (atom goes a step further than webdav
though, in building in provisions for servers to advertise alternate
representations for a resource). caldav and gdata can be viewed as
content-type-aware specializations of the base protocols.

the strategy that i favor is to reuse the atom support we're building
into cosmo for sharing within the ecosystem. cosmo would provide
"sharing format" (whatever that turns out to be - i don't have a
strong opinion) representations of collections and resources. we can
define query parameters that, when sent to collections, return etags
or diffs for resources changed since a certain timestamp or revision
number. similarly, we can define parameters or media types that, when
included with a POST to a collection or resource, specify that the
request content contains diffs rather than full resources. some of the
other sharing requirements - notifications, conflict resolution - we'd
have to think about in more detail.