W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2005

Re: [Fwd: draft-reschke-http-addmember-00]

From: Lisa Dusseault <lisa@osafoundation.org>
Date: Thu, 17 Feb 2005 09:41:55 -0800
Message-Id: <d7593c8a3deb4a6fbf36b4284093afd1@osafoundation.org>
Cc: webdav WG <w3c-dist-auth@w3.org>, Atom <atom-syntax@imc.org>
To: Stefan Eissing <stefan.eissing@greenbytes.de>

On Feb 17, 2005, at 4:58 AM, Stefan Eissing wrote:

> I think What Would Make The World A Better Place is a mechanism that 
> generic clients can discover POST service points where they can 
> persist new entities. There is nothing wrong with POST, it is just 
> that a client cannot discover if and where a server supports that 
> feature.
> Atom solves this problem by embedding the POST service uri into the 
> feed document. That is fine, but
> a) has low reusablity for other protocols/applications
> b) has no usability from the view of a generic client

Not only that, the Atom approach makes it very difficult for a client 
to synchronize a set of items such as a blog in such a way that the 
blog can be authored offline and synched with both local changes and 
server changes.  It might be possible for a specialized Atom client but 
certainly not for an out-of-the-box WebDAV client.

That's what concerns me for the feature of adding a new resource and 
letting the server choose a location -- it would be nice for a tool 
like Sitecopy to still be able to work.  I'm using that more and more 
to get content to  and from sites like ietf.webav.org.

>  I think this is what Julian tries to address with ADDMEMBER, since 
> this method will  be visible in an OPTIONS response. Alternatively, an 
> OPTIONS reponse could carry an extra Header with the URI of such a 
> POST service.

I think ADDMEMBER would be worthwhile if it did have more of an 
extensibility model and provide the ability to support specialized 
applications. For example, some calendar servers need to reject 
non-iCalendar formatted submissions.  ADDMEMBER reminds me a lot of 
MKRESOURCE if it leans in that direction.

Received on Thursday, 17 February 2005 17:42:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:33 UTC