Re: WebDAV and Dynamic Content

>You're right that I would like a gorilla to be able to edit these
>resources.  :)  I think fundamentally that if the WebDAV group decides
>to only support editing static resources and not dynamic resources, it
>will be a limited protocol.  Roy and Brett raised some of the technical
>challenges, but I believe the challenges are just that... challenges,
>and not unconquerable obstacles.

I think you are missing the point.  There are no challenges in what I
described, just choices -- the ability to edit dynamic resources is
already present in the protocol.  The challenge you are describing is
how to represent the protocol actions to the user, which I just don't
think is relevant.  A "smart" client can represent the protocol actions
however it wants, including as if the client were "editing" the dynamic
resource, but this does not change the protocol one bit.

The protocol must perform operations on static content because that
is the only way it can be done.  You don't edit the output of a C program;
you edit the static content of the code that becomes that program.
One way or another, the client must be informed that the content via GET
is from a derived source and thus must be edited at the source(s).  But
what the client sees and the user sees are two entirely different concepts.
A smart client will understand the meaning of a "you can't edit me, go over
there to my source" response and present it to the user in such a way that
an author will understand.  If they don't understand it, then they really
aren't the author of that resource and the right thing to do is to tell
them to piss off rather than mistakenly replace a derived resource with
the wrong content.

>Ok, I'm making the assumption that a client using WebDAV to retrieve a
>resource could be knowledgeable enough to request either the source or
>processed version of the code (because of added functionality in the
>WebDAV protocol).  For static content, this would be the same.  The
>client could therefore know not to let a user edit the processed results
>and store those back over the source code.  I'm suggesting we add
>something to WebDAV to make it aware of the difference between processed
>and source, and NOT force clients guess.

That is already present in the protocol, as the source property.
The reason that the source isn't advertized as a external link on every
GET response is because some people don't like to publish how their
resources are generated, and it doesn't make an efficient tradeoff given
that a typical resource is going to be GET'd millions of more times
than it will be PUT.

>Well, you can probably guess I'm not convinced.  I'm just hoping to
>point out to the group is that this is very, very useful functionality,
>and I consider it short-sighted to limit WebDAV to only support static
>resources, especially with the proliferation of server scripting
>languages where code is embedded within content (typically HTML).  The
>WebDAV group can decide they do not wish to support dynamic content (as
>it seems to have already been decided).  To that I'll add that I think
>vendors implementing WebDAV (such as Microsoft and others as WebDAV
>grows in acceptance) will end up supplying this functionality outside of
>the WebDAV standard if the standard will not grow to support it.  This
>will lead to proprietary headers, or other short-sighted and limited
>ways of doing this (that Roy and Brett and you and many others will be
>able to point out the flaws to).  I think it's in WebDAV's best interest
>to put it's bright minds towards this problem rather than deciding "not
>my problem" or "we don't support that."

You can rest assured that WebDAV would not have been published as an RFC
if I had even the slightest belief that it didn't support the authoring
of all types of resources present on the Web today, either within the
main draft or as part of collections.  You just have to remember that a
resource does not always map to a singular file, but all resources that
are not static are derived from some other resources, and by following the
derivation tree you will eventually find all of the static things that
must be edited in order to modify the content of a resource.

A server cannot "abstract away" those actions because the server doesn't
know what the user is trying to do.  Assuming that the user is just a
dumb browser-editor would eliminate the ability of the Web to support
more sophisticated clients, thus artificially restricting the variety
of Web applications.  A user agent, on the other hand, knows its own
intended purpose (e.g., web editor, file editor, folder manager,
maintenance spider, etc.) and is capable of presenting the raw WebDAV
protocol actions in a way that can be understood by its own user, at
whatever level of sophistication you deem appropriate.

The same principles that apply to dynamic content also apply equally to
content negotiation, scripts, servlets, configurations, versioning, etc.
This is why the Web works.

....Roy

Received on Sunday, 21 November 1999 22:15:29 UTC