Subject: RE: Crossserver ops and lock token swapping.

From: "Yaron Goland (Exchange)" <[email-masked]>
Date: Fri, 10 Sep 1999 16:33:21 -0700

One of the first lessons learned years ago in the database world is to
absolutely never put any useful information into an identifier. It always
bites you. As such servers that put useful information into their lock
tokens are basically guaranteed to be badly written. In this case the first
manifestation of this "brokenness" will be when they try to coordinate with
other servers.

While it is true that we can hack up the protocol to make it support
allowing the lock token to be changed on a request by request basis this is
an abysmally bad idea. For example, imagine that after the response with the
new lock token is sent the connection is lost and the client never actually
receives the response. The client can, of course, perform lock discovery on
the destination (after checking that the source is gone) and get the new
lock token. The only problem is that the client now doesn't know if the
resource has been locked the whole time. For example, did another program
also under the user's control happen to ask for a lock on the resource, thus
explaining why the program can access the lock? Because the lock token isn't
the same there is no way for the program to know if the lock it took out was
outstanding the whole time so any consistency guarantees provided by the
continuing existence of the lock are abrogated and the client is S.O.L. Of
course we could try to work around this problem by either providing some
sort of lock equivalence statement or using timers but those lead to their
own complications.

Given that the whole reason to jump into this pit is to enable servers to do
something they manifestly should never do I would recommend that the lock
tokens be required to remain the same.

		Yaron

> -----Original Message-----
> From: Greg Stein [mailto:[email-masked]]
> Sent: Friday, September 10, 1999 2:45 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Crossserver ops and lock token swapping.
> 
> 
> [email-masked] wrote:
> >...
> > I'd like to propose that moving a lock across servers not 
> change the lock token
> > for a lock on that moved resource..  The reason I say this 
> is because we are
> > claiming in the proposal that locks are on resources... not 
> bindings or URI's.
> 
> This is rather neat philosophically/academically, but from a pragmatic
> standpoint, I don't think it really holds water.
> 
> Let's just take a simple example of a resource being moved from a
> filesystem into a database. The filesystem prefers scheme X 
> to represent
> the locks. The database prefers Y. Sure, they could both use
> opaquelocktokens, but they aren't -- they're each using a scheme to
> optimize their behavior.
> 
> Now what are you going to do?
> 
> I say the MOVE allows the lock token to change, or it just isn't going
> to happen.
> 
> > Well, a MOVE operation is basically just a rebinding and in 
> that sense, the
> > resource itself has not moved.   MOVE just changes some of 
> the URI's at which
> > resources are accessable.  In this case the resource(s) is 
> now accessable via a
> 
> Again: neat philosophy. Go implement this and I'll buy it.
> 
> >...
> > move them.  Can we actually expect unsophisticated servers 
> to actually support
> > locks generated by other servers?  So this suggests...
> 
> Nope. But that was probably a rhetorical question :-)
> 
> >    1) MOVE does not move locks from source to destination 
> in any sense.  (But
> > this breaks model of resource is what is locked.)
> 
> Works for me.
> 
> [although, as I stated in reply to Judy's initial proposal: I'm also
> fine with moving the lock. I think it isn't making as much 
> sense (to me)
> to move it, though. more below]
> 
> >       or
> >    2) We let the destination reassign lock tokens.  (Is 
> this situation important
> > enough to take this approach and complicate the spec? And 
> wouldn't they still
> > face authentication issues?)
> 
> I prefer this option.
> 
> Why not just allow the MOVE to return a Lock-Token header? The
> Lock-Token header would specify the lock that the (moved) 
> resources now
> fall under at the destination.
> 
> There is an issue, though: what of the old locktoken? Did it get moved
> (and changed) or did it remain? Hrm. This isn't an issue, 
> though, if we
> state that it always remains (yes, this is different than 
> Judy's latest
> proposal; it also follows my suggestion about it remaining and
> establishing a locknull resource). If the lock remains, then 
> client can
> always know what happens -- the source lock remains, the resource now
> falls under the lock specified by the returned Lock-Token.
> 
> >       or
> >    3) MOVE wouldn't be allowed between these these servers. 
>  The client would
> > have to use
> > DELETE/COPY/DELETE.  (Keeps protocol simple.  Probably is 
> good enough for those
> > with cheap servers.)
> 
> This is *always* an option. A server can always return Bad 
> Gateway if it
> chooses not to do a move.
> 
> > 
> > Thoughts?
> > 
> > Further thoughts on cross server.  As some have pointed 
> out, right now the spec
> > is nowhere near close enough to actually enable two 
> independently developed
> > servers to do cross server operations besides possibly 
> COPY.  Things like
> > cooperative authentication and lock and binding protocols 
> are are needed.  And
> > we need to specify that lock tokens be standardized.  (We 
> might want to address
> > this now rather than retrofit this later.)  (Judith pointed 
> this out.)  So are
> > we agree'ing that WebDAV is to be cross server 
> friendly/compatible... but not
> > enabling?  (Is that what Yaron was trying to say? :-))
> 
> I believe Yaron was trying to say that we should not be considering
> server-to-server communication. The WebDAV charter explicitly states
> that this is not in scope. As a result, any portion of the 
> specification
> that are necessary *only* for server-server communication should be
> axed. If you can argue a DAV client would use it, then it can stay :-)
> 
> Cheers,
> -g
> 
> --
> Greg Stein, http://www.lyra.org/
>

---

From: Greg Stein <[email-masked]>
Date: Fri, 10 Sep 1999 17:10:07 -0700

Yaron Goland (Exchange) wrote:
> bites you.

Forgive me if my jaw hits the floor.

Database tables use column values all the time for primary keys. You do
*not* have to always create an "id" column. Yes, you usually do when you
have various foreign-key relationships (as part of the process of
normalizing your database design), but there is *nothing* in database
relational theory that requires the addition of an extra column simply
to refer to rows in a database.

A URI is a unique value which contains useful information. If I have no
foreign key relationships or I don't want to normalize my tables, then
why do I have to munge that into something else? That's bunk. Useful
info can definitely be part of an identifier. I can cite examples :-)

> As such servers that put useful information into their lock

I disagree with your assertion. Let's say that I have a repository
(table) with two columns: a database-assigned unique serial number
("id"), and a binary blob. I use this table to store the resources on my
server. When I generate a locktoken, I want that token to specify the
resource's "id" for efficiency purposes.

If the WebDAV spec does not allow that, then it is broken. As it is
currently written, it *does*, but it seems like you're trying to say
that all locktokens should be uniform, regardless of repository. NFW.

I don't see how you can assert that my server would be "badly written"
because of this feature. What makes you believe that? I see no support
for your position.

Coordinating with other servers is beyond the scope of WebDAV. Further,
when/if this server-server communication begins to be designed, then
you're going to need to deal with different locktoken designs simply
because servers are going to want to have opaque/private locktokens. I
know that I want custom locktokens.

> an abysmally bad idea.
> [snip: discussion of why changing tokens is bad]

Excellent point! I agree with you here. That leads me to believe that
locks MUST NOT move with the resource since the Destination may not
support the transfer of the locktoken (heck, what happens if the
Destination doesn't support locking!).

However, I still disagree on your notion that locktokens cannot be
defined by the server (to include useful info). And I *really* disagree
with your (unsupported) view that this implies the server is badly
written.

Cheers,
-g

---

From: John Stracke <[email-masked]>
Date: Fri, 10 Sep 1999 21:04:16 -0400

Greg Stein wrote:

> Useful

Eric the Red.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |"We can't duplicate the bug." "Have you tried|
[email-masked]|the Xerox machine?"                          |
\==============================================================/

---

From: John Stracke <[email-masked]>
Date: Fri, 10 Sep 1999 21:11:17 -0400

Greg Stein wrote:

> That leads me to believe that
> locks MUST NOT move with the resource

It occurs to me that the biggest reason you'd want to MOVE the lock is because
you want to keep control over the resource in the new location.  Couldn't you do
that by locking the destination and then MOVEing the resource?

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |NT's lack of reliability is only surpassed by|
[email-masked]|its lack of scalability. --John Kirch        |
\==============================================================/