Re: Can you move a locked file?

   From: Greg Stein <gstein@lyra.org>

   I totally agree with Yaron here: if I'm editing a document (with a lock),
   then it sure as hell better not move on me. That is just annoying and
   wrong.

It's also annoying and wrong for a resource that is on my favorites
list to be moved away and have me get a 302 back.  Why not just leave
the darn thing where it is?  Well, there are sometimes good reasons to
move it.  And these reasons also apply, even if someone currently has
a write lock out on some leaf resource.  Luckily, it's quite easy to
cope with a 302, so life goes on.

If the proposal was that a server MUST allow the move and MUST
provide 302's, I could see the server writers complaining.  But that's
not the case.  A server is free to block the move, if that's what it
thinks best serves its customers (or is the easiest to implement).

I agree that getting a 302 on access to a locked resource would be
new behavior, but I have heard no arguments (convincing or otherwise :-)
as to how a 302 would be hard for a client to deal with.

   This whole business about the server retaining redirects after a move of a
   locked resource seems really and arbitrarily complex. Why support
   something like that? Just say a server MUST refuse a move of a locked
   resource rather than "well, it might or it might not, but you really won't
   know unless you try."

What causes something to be renamed by a versioning server is not just
a MOVE operation, but rather any change to any metadata that affects
the revision selection for a versioned collection.  Unless it
re-computes all revision selection rules for all versioned collections
before *any* requested metadata change (i.e. moving a label, changing
the member of a configuration), it won't know whether or not the name
of a locked resource will change.

So although a versioning server can always tell you where your
versioned resource is, it is computationally infeasible for it to
detect whether the name of a locked resource is affected by a change.
I'm just looking for a compromise that gives us interoperability
between down-level clients and versioning servers.

   And if this nonsense does go thru as a "consensus change" to the move/lock
   behavior, then the default should be to refuse the move.   There was a
   suggestion that an app should set a flag to state that it can't support
   locked resources that may move -- that's backwards since the current
   behavior is "I lock it and it stays there until I unlock it." In other
   words, an app should say "I can support you [the server] moving this
   locked resource on me and sending me a 301 response."

I personally would not favor any flag that splits the locking behavior
into two different flavors.  Since I can't imagine clients putting in
alternative code paths for these different flavors of locks, this just
guarantees non-interoperability, as each flavor of server fails a
client's request to provide the other flavor of lock.

We should just pick one interoperable semantics.  I'd just like us
to pick a semantics that is implementable by both versioning and
non-versioning servers.

   (I still don't like it though because of the additional complexity on the
   client, which people seem to be ignoring, much to Yaron's dismay; who on
   this list is actually writing client software/tools/apps?)

Every versioning server implementor on this mailing list that I know of is
also a client implementor.  This is also true for all the document management
system server implementors that I know of.

   Personally, I'll refuse the darn move. I'm not going to start recording
   all these redirects on the server.

I'd be against any protocol that required you to do otherwise.  I'd
just like to see us produce a protocol that is compatible with
versioning (after all, this is Distributed Authoring and Versioning :-).

Cheers,
Geoff

Received on Wednesday, 27 October 1999 00:28:54 UTC