W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 1997

RE: Last call: range locking

From: Quentin Clark <quentinc@MICROSOFT.com>
Date: Mon, 3 Mar 1997 22:51:14 -0800
Message-ID: <c=US%a=_%p=msft%l=RED-08-MSG-970304065114Z-2110@INET-04-IMC.microsoft.com>
To: "'Christopher Seiwald'" <seiwald@perforce.com>, "'ejw@ics.uci.edu'" <ejw@ics.uci.edu>, "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>, Yaron Goland <yarong@MICROSOFT.com>

By way of introduction, I work as a Program Manager at Microsoft on the 
Internet Information Server (IIS).  I am working with Yaron on DAV issues, 
as well as other web protocols (among other things).

I too am unaware of source control products that have byte-range level 
locking.  However, most OS's that I am aware of do.  Since one of the 
practical uses of the DAV methods will be to extend local file systems to 
web servers, it appears to be very appropriate.

As far as the cache invalidating argument goes, while certainly it seems to 
make sense, I don't think resources that are going to be partially locked 
are going to be necessarily fully read.  As an example, imagine a web 
application that maintains a database of information which is implemented 
as a single file for performance reasons.  Modifying this over HTTP could 
be implemented by partial GETs, LOCKs, and PUTs.

I am failing to understand the objection to keeping range-locking in-scope. 
I think it should be kept in.

Quentin Clark
Program Manager
Internet Information Server

-----Original Message-----
From:	Christopher Seiwald [SMTP:seiwald@perforce.com]
But few (no?) existing version control systems provide range locking.
So you'd be breaking new ground -- not necessarily the best thing for
a standards body.

Christopher Seiwald     Perforce Software          1-510-865-8720
seiwald@perforce.com     f-f-f-fast SCM   http://www.perforce.com
Received on Tuesday, 4 March 1997 01:58:19 UTC

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