Re: Ideas: GETSRC & MULTIPUT

On Mon, Oct 29, 2001 at 05:16:41PM -0800, Jim Whitehead wrote:
> > Under what conditions did it not work?  Do you mean just never
> > implemented?
> 
> The source link was never implemented.

Well, that's a hell of a lot easier to fix than to rewrite a standard and
all of the models upon which it is based.

> The two reasons I have heard for this (there may be more) are:
> 
> (a) Server implementors did not want to handle the namespace complexity of
> automatically creating new areas of the namespace for source resources. That
> is, on most servers, the source resources would be "synthetic" -- the server
> would be making up the URL for the source resource, and would be managing
> interactions with this synthetic resource.

Huh?  Then how are they going to handle the different access control and
behavior necessary for synthetic versus static resources?  You can't PUT to
a CGI script's synthesis URI and expect to edit the source because it is the
Common Gateway Interface, which necessarily requires that the PUT be gatewayed
through to the script itself.  Trust me on this one -- the notion of GETSRC
as you described it cannot be implemented on the Web.  That only makes sense
for files, not resources, and even then only files that do not contain any
subsidiary resources as inclusions.

> (b) There was insufficient direction given to client implementors on how to
> use and handle the source link, especially in the case of multiple sources
> for a given resource. The user interfaces of almost all existing DAV clients
> implicitly assume there is just a single "source" representation for a
> resource. Perhaps DAV's closeness to a traditional network file system
> protocol is coming back to haunt us. Certainly, it would involve significant
> UI and operational shifts to accommodate more.

So the solution is to make it impossibe to edit resources that consist of
multiple sources?  That'll really piss off my customer who has spent most
of this year creating a site that is entirely controlled by a content
management system, where each resource consists of a dynamic mapping to a
database entity catalog.  Each Web page consists of dozens of source elements.
It isn't using webdav right now, but it would be a shame if webdav couldn't
support existing CMS functionality.

> I think existing client UIs could handle a standard mechanism to get at 1
> source representation for a resource. I do not think they can handle a
> mechanism that provides access to multiple source representations. Efforts
> to do so will, like the source link, be ignored. I think it is instructive
> that the only mechanism that has gained any traction so far is the Translate
> header, which provides access to one source representation.

If it doesn't support the Web, then it doesn't qualify for the name WebDAV.
Feel free to define yet another distributed filesystem protocol within any
other working group of the IETF.  I'd rather wait until it gets implemented
correctly than reduce the standard to something that doesn't meet the need.

....Roy

Received on Tuesday, 30 October 2001 03:36:43 UTC