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

From: [email-masked]
Date: Mon, 18 Oct 1999 11:57:14 -0400

The lock can expire for the principle owning the lock, not the lock token. This
implies a principle can't own multiple locks on the same resource which is
already the case.

John Stracke <[email-masked]> on 10/18/99 11:26:39 AM

To:   [email-masked]
cc:

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

[email-masked] wrote:

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

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]|                                             |
\==============================================================/

---

From: [email-masked]
Date: Wed, 27 Oct 1999 15:15:10 -0400

Geoff, I'm going online with this one....

    My thinking is that it could be possible for a collection to have a body,
but we
    haven't defined how that works?

    As far collections often getting their content from elsewhere...  that does
kind
    of sound like something we'd see in a live/active/dynamic resource.  But
that
    doesn't mean a collection couldn't have a body.  We just don't seem to have
a
    reason to support or disallow it.

    If it does have a body... I would expect it to be locked.
    If it's getting it's body via another resource (and perhaps has a source
    property)... I would think the lock wouldn't matter since the client would
go to
    another location to modify the source.

  The sense in which it matters would be that we need to let clients and
  servers know whether or not the collection lock "applies" to the "body",
  especially if that body is some other resource.  If it does apply, then
  servers must lock that other resource in addition to the collection
  (and clients must expect this behavior).  Leaving this undefined would
  leave clients and servers not knowing what to do in this case.

Never mind.  The more I think about it the more this becomes a rat hole.  It's
too
similar to live resources and I don't want to get anywhere near that rathole.
We're having a hard enough time dealing with locks.  :-)

I'll add locking of collection body to the list of locking issues, but I'd
almost
certainly defer discussion until the rest of locking is firm.