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

RE: LOCK fragments of Web Resource

From: Yaron Goland <yarong@microsoft.com>
Date: Fri, 20 Nov 1998 14:24:34 -0800
Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792A38@RED-MSG-59>
To: "'jwagner@danetis.is.danet.de'" <jwagner@danetis.is.danet.de>
Cc: "Alex Hopmann (Exchange)" <alexhop@exchange.microsoft.com>, smangat@Adobe.COM, w3c-dist-auth@w3.org
1) Please refer to the mail archives where we discuss issues of range
locking and partial updates in gross detail. I would specifically look for
discussions of the PATCH method.

2) As for timeouts and such in WebDAV please see section 9.8 of the draft
which covers the issue in some detail.

			Yaron

-----Original Message-----
From: jwagner@danetis.is.danet.de [mailto:jwagner@danetis.is.danet.de]
Sent: Friday, November 20, 1998 2:15 PM
To: Yaron Goland
Cc: Alex Hopmann (Exchange); smangat@Adobe.COM; w3c-dist-auth@w3.org
Subject: 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:36:26 GMT

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