Re: resourcetype locknull

   From: ccjason@us.ibm.com

      Given the preponderance of evidence that indicates this is a difficult
      feature to implement,

   Jim, could you point me to that evidence.  Earlier today Geoff defered
   that question to a note he said JimA wrote.  I did a search for it
   and didn't find it.  The best I've been able to find is simply
   folks saying it's hard... but not explaining why.  I'd like to
   document this.

Jason: Both Jim and I were referring to the fact the server
writers that have contributed to this thread have said that lock null
resources were unpleasant/hard to implement, and that they'd prefer to
see them removed from the spec.  You are correct the reasons for why
it was hard were not detailed.

My arguments have largely been focused on the fact that they don't do
much for a client, and in some ways can make life harder for both clients
and users.

As a server writer, the following are some of the problems with lock null
resources:

They don't act like normal resources.  They return 404's to a GET
as if they didn't exist, but show up in PROPFIND's.  Are they a binding,
and therefore part of the state of a collection, or something else?
If you have a versioning server, do you have to checkout a collection
in order to add a lock-null resource to it, or not?  If you checkin a
versioned collection that has a lock-null resource in it, does that
make that lock-null resource "immutable" (whatever that means)?  Do you
have to checkout the versioned collection in order to remove a lock-null
resource from it?  When you do a DELETE, does that delete the lock-null
resource at that spot, or does it leave it alone?  When you DELETE a
locked resource, should it delete the lock, or leave a lock-null resource
in its place?

Those are a few of the questions that a server writer must answer, and
then hope that the client writers are expecting that behavior.  And then
the server writer has to figure out how to model this behavior with their
underlying implementation objects.

Let me know if you'd like more ... (:-).

Cheers,
Geoff

Received on Thursday, 14 October 1999 23:04:22 UTC