RE: DAV-Enabled field (was RE: A case for GETSRC)

>  >	(2) In a general-purpose web server there is a very real
>>  messiness with trying to get the right DAV:source property onto all
>>  of the dynamically generated resources.  A web server may have dozens
>>  of modules that dynamically generate content, all of which might have
>>  very different definitions the URI spaces that they handle.
>
>It's not clear to me why in this scenario using the same URI would be
>better.

It would be better from the user's point of view.  And it is easier 
from the server's point of view because the DAV module only has to 
worry about what is on the file system, not all possible URIs that 
might be supported  by the sum total of all configurations of all 
modules running on the server.

>  >	(4) You don't get anything extra with DAV:source beyond what
>>  you could have with Translate.  (Until DASL and friends make the
>>  scene, that is.)
>
>I disagree. For instance, you get separate identifiers for separate things,
>conform to HTTP, do not invent new methods, don't break proxies (...to be
>continued...).

Having separate identifiers is not a benefit.  As I have explained 
repeatedly, it is often a detriment.  *If* people want to view output 
with their DAV clients and view source with their browsers, *then* it 
is a benefit.  Since the benefit of splitting the source/display 
views into separate resources/URIs is very situation-specific, it 
should not be mandatory.

"Conform to HTTP" is debatable.  Returning the source for a GET if 
that's the intended policy could be interpreted as compliant with the 
HTTP spec, if you hold your head just so.

"Doesn't break proxies" is solvable with the Vary field, and is a 
minor implementation detail.

In short, in most cases you don't get anything.

>The remark about DASL is interesting. Could you elaborate?

DASL makes things more interesting because it allows for searching on 
properties.  You might have content with properties that need to be 
searchable, generated by sources with a very different set of 
properties.  (eg: a single source document that generates several 
display documents with searchable properties of different values.) 
Since in this case you _want_ different properties between 
source/display views you get a real benefit from splitting them into 
separate resources with separate URIs.

I confess to not having read the spec, but it sounds like ACL is 
interesting because you could allow the NaturalSciences department 
(as an example) to restrict GET, HEAD, and POST operations in some 
display spaces and assign authoring/editing rights internally in some 
other spaces.  In short, it might allow  for a very author-driven 
security system instead of an administrator-driven one (without 
resorting to editing .htaccess files).  Still, if you had a way to 
differentiate between GET and GETSOURCE, you wouldn't necessarily 
benefit from splitting the source/display resource, but it still 
might be very convenient to do so.

This is why I keep coming back to the desireability of DAV:source. 
It should be fixed, and its support encouraged.  But there also needs 
to be room for people who prefer the simplicity of the single URI, 
who just use DAV for messing with source, and who don't benefit from 
differentiating source/display URIs.

cjh

--

Received on Wednesday, 6 March 2002 16:41:09 UTC