W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2007

RE: New draft: draft-daboo-webdav-mkcol-00.txt

From: Cyrus Daboo <cyrus@daboo.name>
Date: Mon, 12 Nov 2007 12:18:20 -0500
To: John Barone <jbarone@xythos.com>, WebDAV <w3c-dist-auth@w3.org>
Message-ID: <6AB4820043D1A43227496BBE@caldav.corp.apple.com>

Hi John,

--On November 12, 2007 8:50:55 AM -0800 John Barone <jbarone@xythos.com> 
wrote:

> I'll qualify this by saying I haven't read the spec yet (and I promise,
> I will), but why just MKCOL; why not PUT as well (maybe BIND too??? ...
> any method where you create an object)?   Again, without having read the
> spec. yet, seems like this might be focusing in on too specific a use
> case.
>
> I can see this being very useful for setting up collections that are
> meant to be used as "application bundles", but why not try to propose a
> more generic spec. that allows for applying meta-data templates to any
> resource.
>
> ... of, course easy to say from the sidelines; I should also say that
> Xythos would be very interested in contributing to/reviewing such a
> spec.

The extended MKCOL spec is focussed solely on addressing the current issue 
of too many MKxxx methods.

It would be a little more complex to do this with PUT. The reason it is 
easy with MKCOL is that the existing MKCOL does not take a body, so the 
extension data can be put in the request body.

With PUT, there is already a body being sent - i.e. the actual data of the 
resource. So there is no place to put the extension data, except for the 
request header (which would not be ideal). One solution, of course, would 
be to use a special MIME body with PUT, e.g. a multipart/mixed where the 
first part is application/webdav+properties, and the second part is the 
actual resource body data. Not sure what implication that might have.

-- 
Cyrus Daboo
Received on Monday, 12 November 2007 17:18:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:15 GMT