Fwd: [uf-rest] Roy Fielding on WebDAV and PROPs

[Mark Nottingham]

Forwarding with permission, as Yaron's offlist.

Begin forwarded message:

> From: "Yaron Y. Goland" <yaron at goland.org>
> Date: April 12, 2006 9:46:44 AM PDT
> To: Mark Nottingham <mnot at yahoo-inc.com>
> Cc: Microformats REST <microformats-rest at microformats.org>, "Dr.  
> Ernie Prabhakar" <drernie at opendarwin.org>, Jim Whitehead  
> <ejw at soe.ucsc.edu>, Larry Masinter <LMM at acm.org>
> Subject: Re: [uf-rest] Roy Fielding on WebDAV and PROPs
>
> Yes, Roy did make those arguments and the group rejected them for  
> the reasons explained (briefly) in  - http://lists.w3.org/Archives/ 
> Public/w3c-dist-auth/1998OctDec/0074.html. (BTW, this is from the  
> WebDAV Book Of Why which answers lots of questions about why we did  
> what we did in WebDAV - http://www.webdav.org/papers/).
>
> The interesting question is - now that it's nearly 8 years later  
> have server processing speeds (and cheap database availability)  
> increased to the point where using some kind of URL munging would  
> make sense? I'd argue that you will still need the prop methods for  
> on-the-wire performance (HTTP never did get box caring right for  
> non-idempotent methods) but it may indeed be time to add a URL  
> munging attack (I'm sure Larry will be unhappy) with the  
> stipulation that the munging only applies to WebDAV resources. I,  
> for one, certainly always wanted properties to get their own URIs.
>
> 		Yaron
>
> On Apr 11, 2006, at 4:35 PM, Mark Nottingham wrote:
>
>> Yaron and I used to fight about (er, "discuss") this. Hi, Yaron :)
>>
>> He and Jim Whitehead wrote a paper about the property design of  
>> WebDAV that explained their requriements and choices; see:
>>    http://www.goland.org/spe-whitehead.pdf
>> It might be helpful reading.
>>
>> My preferred way to do this is to turn
>>   PROPFIND /foo
>> into
>>   GET /foo,properties
>> where ",properties" is a site-configurable string. It needs to be  
>> advertised by some sort of site metadata; e.g., in OPTIONS *, or  
>> in a response header (although that's arguably a waste of bytes).
>>
>> There's also the case of getting the properties of multiple  
>> resources, or filtering the properties you get server-side; this  
>> should also be possible, e.g.,
>>   GET/foo,properties;prop1;prop2;depth=infinity
>>
>> I totally agree with Roy about WebDAV ACLs, but haven't yet seen  
>> any other model come forth.
>>
>> Cheers,
>>
>>
>> On 2006/04/11, at 2:32 PM, Dr. Ernie Prabhakar wrote:
>>
>>> I've always felt there was something wrong with WebDAV, and Roy  
>>> did a nice summary of what over on rest-discuss:
>>>
>>> On Apr 11, 2006, at 12:40 PM, Roy T. Fielding wrote:
>>>> PROP* methods conflict with REST because they prevent
>>>> important resources from having URIs and effectively double the
>>>> number of methods for no good reason.  Both Henrik and I argued
>>>> against those methods at the time.  It really doesn't matter
>>>> how uniform they are because they break other aspects of the
>>>> overall model, leading to further complications in versioning
>>>> (WebDAV versioning is hopelessly complicated), access control
>>>> (WebDAV ACLs are completely wrong for HTTP), and just about every
>>>> other extension to WebDAV that has been proposed.
>>>
>>> The interesting question for me is what the "right" way to do  
>>> properties would be over HTTP.  I presume it would require some  
>>> sort of convention for a property namespace, which implies non- 
>>> opaque URLs.  Which in term (in order to be RESTful) would  
>>> require the *server* to have some way to tell clients about it,  
>>> since clients shouldn't *assume* URI structure.
>>>
>>> Any thoughts about the optimal way to do that?
>>>
>>> -- Ernie P.
>>>
>>> _______________________________________________
>>> microformats-rest mailing list
>>> microformats-rest at microformats.org
>>> http://microformats.org/mailman/listinfo/microformats-rest
>>>
>>>
>>
>> --
>> Mark Nottingham
>> mnot at yahoo-inc.com
>>
>>
>>
>
>

--
Mark Nottingham
mnot at yahoo-inc.com