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

Re: LOCK fragments of Web Resource

From: Jim Whitehead <ejw@ics.uci.edu>
Date: Fri, 20 Nov 1998 14:28:18 -0800
To: WEBDAV WG <w3c-dist-auth@w3.org>
Message-ID: <000101be14d5$12a5d500$d115c380@galileo.ics.uci.edu>
Accidentally caught by the spam filter. I have added Juergen's email address
to the accept2 list for the w3c-dist-auth list, so future emails from this
address should go through (actually, I do this as a matter of policy for all
email addresses which are accidentally caught by the spam filter).

- Jim

-----Original Message-----
From: Juergen Wagner [mailto:jwagner@danetis.is.danet.de]
Sent: Friday, November 20, 1998 2:15 PM
To: Yaron Goland
Cc: alexhop@exchange.microsoft.com; smangat@adobe.com;
w3c-dist-auth@w3.org
Subject: [Moderator Action] Re: LOCK fragments of Web Resource


Locking simply on the basis of byte ranges requires knowledge about
the structure of data objects on the client side, which is not good
for obvious reasons. Also, we have to consider that many resources may
have more than one external representation, depending on the URI used
to access a particular resource. Therefore, locking seems to be a
content-specific issue (e.g., locking a particular substructure of an
XML document, a record in a fixed-length record file, a sequence of
images in an MPEG video, etc.). There probably should be a segment
specification syntax (hopefully with some generic elements) allowing
MIME types to define their specific form of locking a particular
sub-unit (segment). This would entirely hide the internal
representation of data objects/resources from clients (irrespective of
the fact that some resources might be created on-the-fly). Note also
that the same mechanism may need to be applied if an application
chooses to delete or update such a sub-unit (which again is a topic
WebDAV might want to consider at some point).

I suggest that locks should also contain a timeout (after which they
may be released automatically) and/or a refresh period (when expired,
the locking entity has to reinforce the lock, otherwise it may be
released after some timeout) to avoid dangling locks some clients have
long forgotten (or because Windowz crashed ;-( again).

--Juergen

danet is GmbH			Fon: +49 (0) 711 13353-25
Waldburgstr. 17-19		Fax: +49 (0) 711 13353-53
D-70563 Stuttgart		wagner@danet.de
Germany				wagner@cs.stanford.edu


According to Yaron Goland:
>
>There was work done in this area to support the use of the range header and
>the LOCK method. However just trying to support byte range locks turned
into
>a bottomless pit. What was worse was that we quickly figured out that byte
>range locks wouldn't be sufficient. As such the group wisely decided to
skip
>this rat hole.
Received on Friday, 20 November 1998 17:33:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:48 GMT