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....

<GC>
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
servers.
</GC>
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...


<GC>
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.
</GC>
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.

Cheers,

Jason.
Received on Thursday, 19 August 1999 20:29:45 GMT

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