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

Re: Locking: Implementation Considerations

From: <ccjason@us.ibm.com>
Date: Thu, 19 Aug 1999 20:28:15 -0400
To: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
cc: JSlein@crt.xerox.com, w3c-dist-auth@w3.org
Message-ID: <852567D3.0002B3B6.00@D51MTA07.pok.ibm.com>

GEoff, before you go on vacation, it would probably be valuable if you were your
own devil's advocate here....

So what conclusion can one draw from all this?

One possibility is to say that locking is largely unneccessary in the
presence of versioning (after all, everything is read-only unless you
explicitly check it out into your workspace), so versioning servers
just won't bother with locking at all.  This would have an unfortunate
interoperability result on Class-2 clients try to work with versioning
So why *NOT* let versioning replace locking?  Is there a form of locking that
provides value add over versioning?  How mature is the versioning work?   Be
your own devil's advocate...

Another possibility is to downgrade Depth:infinity locking to a MAY,
thereby warning clients that they are likely to find this not supported,
and to turn the default lock into Depth:0, instead of Depth:infinity.
The latter will cause an interoperability issue with existing class-2
servers, but since there aren't many of those yet, if we move fast, this
would probably be OK.
There must be issues with your first proposal or you wouldn't have offered this
one.  Let's hear them.  :-)

I just want to get your thoughts here before you go.  I'm sure we'll all be
discussing this while you're gone.


Received on Thursday, 19 August 1999 20:29:45 UTC

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