RE: Status code for creating lock-null resource

Dan has lots of good stuff in this message that I'll want to
follow-up on, but I first wanted to focus on one particular
comment:

   From: Dan Brotsky [mailto:dbrotsky@Adobe.COM]

   Geoff is suggesting something slightly different: that LOCK not
   even be allowed on unmapped-URIs.  This also gets rid of LNRs and
   has the advantage that you always know whether something is a
   collection or not.  However it doesn't allow users to
   simultaneously create and LOCK resources for further editing, which
   bothers me.

Could you expand on why this bothers you?  Since (I believe) this is
the only thing that you gain with "unmapped URI locks" (UULs,
previously known as LNRs :-), it is important to understand why (or
whether) this matters enough to warrant the kind of confusion and
complexity that UULs bring to the model.

Suppose UULs are supported.  If you issue a LOCK against an unmapped
URI, this may fail because someone already has a lock on that URI.  In
this case, you either need to wait until that lock is removed (at
which time, it is likely there is a resource mapped to that URI, but
maybe not), or you need to try again on a different URI.

Now suppose UULs are not supported.  You can't issue a LOCK against an
unmapped URI, so instead, you first create a resource *of the
appropriate type* and then try to LOCK that.  This LOCK request may
fail because someone already has a lock on that URI.  In this case,
you either need to wait until that lock is removed (at which time, it
is likely there is a resource mapped to that URI, but maybe not), or
you need to try again on a different URI.

Those two cases look very similar (in fact, I copied the text
of the first case into the second case, so they should look
*really* similar :-).  So what do you really gain with UULs?

Note: for compatibility with old 2518 servers, we shouldn't say that a
LOCK MUST fail on an unmapped URI, but we certainly could amend the
protocol to say that it SHOULD fail.  Since UULs act so differently on
current servers, this is probably the only thing we could say, if we
wanted to tell client writers how to achieve interoperability with
existing servers.

Cheers,
Geoff

Received on Wednesday, 27 June 2001 22:53:59 UTC