[Cosmo-dev] Sharing format wiki page
Lisa Dusseault
lisa at osafoundation.org
Wed Jul 12 06:08:08 PDT 2006
On Jul 7, 2006, at 1:39 PM, Brian Moseley wrote:
> 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.
Yes.
>
> caldav requires locking
Nope; but it supports locking if desired by server.
> 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.
Yep.
Also: at a very deep level, WebDAV gives more control to the client,
and Atom gives more to the server, in the basic design of the
protocol. (You could write a WebDAV server that did all kinds of
things to remove control from clients, and you could write an Atom
server that gave as much control as possible from the client, but the
models have this tradeoff inherent in them.)
Comparing WebDAV's collection model, (e.g. PROPFIND collection
listings) with Atom's feed model a little more, some of these points
are inherent in the different designs, and some are accidents of what
features have been defined so far in each protocol:
* Atom's process for adding a new item is simpler (client needn't
choose unique URL)
* WebDAV may scale better to large numbers of collections (fully
hierarchical organization rather than one introspection document)
* PROPFIND allows for greater client control over what
information is returned in listings.
* WebDAV allows MOVE and COPY
* I can see how to synchronize a file system better with WebDAV,
and possibly even a single collection, but I haven't tried to do this
with Atom yet. The Atom model focuses more on recent items than on
the whole membership.
More here: http://www.intertwingly.net/wiki/pie/WebDav
http://www.intertwingly.net/wiki/pie/WebDavVsAtom
Particularly: "WebDAV is a generic solution". Atom is only slightly
less general and creative persons can definitely add all kinds of
stuff to it, but WebDAV's metadata model and client control just
makes it
Also: "Atom is designed to "work within the web", meaning, to be
compatible with EXISTING tools, even tools which aren't quite Atom-
aware". Yes, WebDAV made some more choices that broke with existing
simple HTTP APIs in order to achieve more power/elegance. A
difficult tradeoff.
Also: "Note that Atom's ability to expose detailed interaction links
is very flexible in supporting a multi-hosted sites, possibly
different in some regards from having certain WebDAV collections
hosted in different roots." True.
Finally, having had some experience in implementing and deploying new
protocols, and participating in interoperability events, I must
assume that WebDAV is more mature in its implementation experience --
WebDAV was approved/finalized in 1998, whereas Atom publishing
protocol hasn't been yet in 2006. I do believe Atom design has
benefitted from more experience with designing these kinds of
systems, but it's a safe bet to predict at least some snafus will
turn up that we haven't thought of yet. Atom has great promise;
WebDAV has a decent track record, and if the promise excites you
enough to ignore the track record, you're less cynical than I.
Lisa
More information about the cosmo-dev
mailing list