Subject: RE: Simplifying RFC-2518 Locking: A proposal

From: [email-masked]
Date: Mon, 18 Oct 1999 09:01:27 -0400

---------------------- Forwarded by Jim Amsden/Raleigh/IBM on 10/18/99 09:01 AM
---------------------------

Jim Amsden
10/18/99 09:01 AM

To:   Jim Whitehead <[email-masked]>
cc:

Subject:  RE: Simplifying RFC-2518 Locking: A proposal  (Document link: Jim
      Amsden)

<JimW>
You may be right. But, at this point, more interoperability problems would
be introduced by "fixing" this problem than would be removed by removing
lock tokens.  As your implementation experience shows, client-side handling
of lock tokens is simply tedious, and isn't a show-stopper.  Given a
tradeoff between potentially show-stopping interoperability problems with
existing clients (removing lock tokens from 2518), and a non-show-stopping
programming tedium (keeping things as is), I'm very much in favor of the
status quo.
</JimW>
<jra>
I don't know about  other client writers, but I would be more than happy to take
the lock token handling code out of my clients. It was a lot of work (persisting
them, knowing what methods had to include them, etc.) that seemed to add very
little. I suspect most clients would work just fine if the server returned a
constant for the lock token for compatibility purposes. What do others think?

I would also like to see the spec stabilize. This was just an attempt to see
what other thought, and to be sure everyone knows what these lock tokens can and
can't do.
</jra>

---

From: John Stracke <[email-masked]>
Date: Mon, 18 Oct 1999 11:26:39 -0400

[email-masked] wrote:

> I suspect most clients would work just fine if the server returned a

Constant lock tokens have the problem that they can't expire.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |The plural of mongoose is polygoose.         |
[email-masked]|                                             |
\==============================================================/