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

Re: WebDAV and Dynamic Content

From: Serge Knystautas <sergek@lokitech.com>
Date: Sun, 21 Nov 1999 14:29:24 -0500
Message-ID: <38384814.4B7E79D2@lokitech.com>
To: Jim Davis <jrd3@alum.mit.edu>
CC: w3c-dist-auth@w3.org

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.

Comments below...

Jim Davis wrote:
> There is an understandable temptation to hope (or at least wish) that
> somehow the software agent or server can be make smart enough to "guess"
> whether a URL is being used to refer to the "source" of dynamic resource or
> the result of executing it.  But I do not think this is possible.

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.

> Others have proposed adding a proprietary header that controls the
> processing.  But as Roy as explained, this is a bad approach.

This is probably using your words other than how you meant them, so I
apologize in advance.  To me proprietary header means an individual or
organization owns/invents/only they use that header.  To which I would
respond that if the WebDAV group added a specific header to control
processing, it would no longer be proprietary.

> If you don't find Roy's explaination (and Brett's elaboration) sufficient,
> I will try myself to make the case.  But perhaps you (and others) are now
> convinced?

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."

I hope I haven't ruffled too many feathers.  I'm normally just a lurker
here and will shortly return to that.  Again, I think this is needed
functionality, and if we don't figure out how to support it, others
will, and you'll get splintered efforts with poorly implemented

Serge Knystautas
Loki Technologies
Received on Sunday, 21 November 1999 14:35:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:19 UTC