RE: Simplifying RFC-2518 Locking: A proposal

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


Jim Amsden
10/18/99 09:01 AM

To:   Jim Whitehead <ejw@ics.uci.edu>
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>

Received on Monday, 18 October 1999 09:05:11 UTC