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

Re: Simplifying RFC-2518 Locking: A proposal

From: <ccjason@us.ibm.com>
Date: Wed, 27 Oct 1999 15:15:10 -0400
To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
cc: w3c-dist-auth@w3.org
Message-ID: <85256817.00697DD8.00@D51MTA03.pok.ibm.com>

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.
Received on Wednesday, 27 October 1999 15:12:40 GMT

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