Re: Bindings, Locks, and MOVE

This whole thread (post-Judy's message) seems to be picking out a very
minor detail of her post. Personally, I find this nit-picking of detail
counter to the goal of her original post: "test its conclusions with the
mailing list members."

For myself (and mod_dav), the first "AGREED" portion makes complete
sense, and I do agree with it.
[btw, is *anybody* going to be implementing cross-server MOVE/COPY? is
it necessary to have that feature in the spec at all? of the umpteen DAV
servers out there now, I don't know any that do this or plan to do this.
It would be nice to cut the thing and not worry about it.]

The second "AGREED" portion does not make a whole lot of sense. The
commentary states that the position is too strong [because it might not
make sense with other types of locks]. Are there other locks out there?
Do people have concrete, useful examples? I haven't heard of anything
besides a write-lock yet. Regardless, I think it should be enforced in
the spec that a write-lock MUST have guaranteed protection of the
Request-URI. Put in some language that says other locks can define the
MUST/SHOULD nature of protection. Otherwise, leave it in the intuitive
state: a write lock says that others cannot monkey with your URI.

Cheers,
-g

Edgar Schwarz wrote:
> 
> On Thu, 2 Sep 1999, Geoffrey M. Clemm wrote:
> 
> >    From: ccjason@us.ibm.com
> >
> >    <JS>
> >    This discussion began with Yaron's comment that saying that "it MUST NOT be
> >    possible for a principal other than the lock owner to make a locked resource
> >    inaccessible via the URI mapping used to lock the resource" is too strong.
> >    It may make sense for write locks as defined in RFC 2518, but may not make
> >    sense for other sorts of locks that don't restrict MOVE and DELETE.
> >    </JS>
> >
> >    I believe that this is not specific to any particular type of locks.  All
> >    clients need to insure that they have at the very least a way to unlock
> >    the the locks they have created.  I assume that to unlock (a resource), we
> >    have to provide a URI of a (the?) resource locked by that lock... so if
> >    someone else changes the URI, it's
> >    very likely that we're not going to be able to figure out what the new
> >    URI is... and will have to leave the lock around until it times out.
> >
> > <gmc> Since the server needs to deal with this in case the client just
> > neglects to remove the lock, and if having another client MOVE your
> > locked resource is a rare occurrence (which I believe it is), then
> > this does not seem to be especially problematical.
> Would it be possible to say:
>   If a locked resource is moved the server SHOULD create a indirect
>   reference resource which should exist for some sensible time.
> 
> Yes I know, it's complicating the server :-)
> I imagine the above happening perhaps when somebody is reorganizing
> a directory structure and deep in the collections there are some
> locked resources.
> So the lock owner at least has a decent chance to find out where his
> resource has gone to.
> 
> Regards, Edgar
> 
> --
> Edgar.Schwarz@de.bosch.com ON/EMS1, 07191/13-3382         Niklaus Wirth:
> Privat kann jeder soviel C programmieren oder Videos ansehen wie er mag.
> Albert Einstein:  Mach es so einfach wie moeglich, aber nicht einfacher.

--
Greg Stein, http://www.lyra.org/

Received on Friday, 3 September 1999 03:31:24 UTC