- From: Yaron Goland <yarong@microsoft.com>
- Date: Fri, 20 Nov 1998 14:24:34 -0800
- 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 UTC