- From: Lisa Dusseault <lisa@osafoundation.org>
- Date: Thu, 17 Feb 2005 09:41:55 -0800
- To: Stefan Eissing <stefan.eissing@greenbytes.de>
- Cc: webdav WG <w3c-dist-auth@w3.org>, Atom <atom-syntax@imc.org>
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. Lisa
Received on Thursday, 17 February 2005 17:42:14 UTC