Lock null resources (was RE: Deleting versions)

"Lisa Dusseault" <lisa@xythos.com> wrote:
>
> > No, that's great!<g>  The lock null resource is a nonce concept
> > that is not required by Delta-V.
>
> Since the lock null resource is enshrined in RFC2518, I do not think
> it's merely a nonce concept (yes, I had to look it up :)

Sorry, what I meant was that "lock-null" resources are wierd.  The notion
was introduced for a unique purpose, and it is probably best if we tolerate
it but don't propogate it in Delta-V.

> But you have a point about the purpose, let me try again and see if I
> get it better:  the lock-null feature allows people to lock something
> before it's created so that there's no window, or gap, when somebody
> else can lock it (after it's created but before the creator has finished
> with it). Agreement?

Clients can't "lock something before it is created".  The problem is how to
reserve the namespace for a future resource.  Since HTTP deals with named
resources RFC2518 had to introduce a 'null' resource to get the namespace
locking without providing a meaningful resource entity.

> > I see no argument for VERSION-CONTROL or CHECKOUT, but MKWORKSPACE is a
> > more likely candidate since it is akin to MKCOL.  This would obviously
> > require a modification to RFC2518's statement that the lock null
resource
> > MUST fail methods that are not in the named list.
>
> I agree.  Rather than relying on the not-fully-prescient wording of
> RFC2518, I'd suggest saying that MKWORKSPACE can be allowed on a
> write-locked null resource, but no other DeltaV methods.
>
> The modification to RFC2518 is not required because it states "any
HTTP/1.1
> or DAV methods ".  DeltaV methods, obviously, are not covered by this,
> because if HTTP/1.1 was meant to be inclusive, then DAV wouldn't have
been
> called out explicitly.
> :)

Fine.


Tim

Received on Tuesday, 5 June 2001 06:03:11 UTC