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