Subject: LOCK Scenarios

From: [email-masked]
Date: Tue, 17 Aug 1999 13:46:09 -0400

Jason says:
Just for the sake of consistancy,  I prefer the singleton and depth locks
to be treated the same.  Just as Kevin apparently does.

I'm not sure this treating these locks the same is consistent. They are
different locks on different resources playing different roles in the methods.
As Geoff pointed out, to have a (singleton) destination lock retained on COPY or
MOVE requires a significant number of special cases.

---

From: [email-masked]
Date: Tue, 17 Aug 1999 14:21:41 -0400

Maybe I misinterpretted what it was that he Geoff felt was inconsistant.  He
didn't mention singleton, depth or even exclusive locks.  For this reason, the
inconsistancy that I thought he depicted applies to  singleton and depth locks
equally... and exclusive and shared... and that's what I addressed in my
response to his note.

---

From: [email-masked]
Date: Tue, 17 Aug 1999 16:21:12 -0400

<JC>
In my previous response I voted against retaining a lock for /x/y/z.html.
One other thing I'd like to check...   Is it possible to do a MOVE
operation that replaces a binding to a collection with a binding to a
non-collection?  (This relates to your discussions with JimW over
/x/y/ and /x/y being interchangeable.)
<jra>
You can MOVE a resource over a collection or the other way around. The semantics
are that the overwrite header must be "T", and if so the destination is deleted
before the MOVE.
</jra>

If so...  there might not even be a collection at /x/y after the move
which makes keeping a null lock at /x/y/z.html even odder.  To date,
all null locks have had collection resources at their PARENT URI.
<jra>
All DAV resources have collection resources at the PARENT URI.
</jra>

I'd vote that for now we limit the things so that the only lock that we'd
consider retaining is at the DELETE's request URI.  Any ancestor lock
will be retained.  Any descendent lock will not.
<jra>
Yet another special case. The current spec has no such special cases. Inheriting
a depth infinity lock from the destination parent collection is not a special
case, its part of what it means to be a memeber of a collection.
</jra>

Note: all of our discussion retaining destination locks also applies
to an overwrit'ing BIND.
</JC>

---

From: [email-masked]
Date: Wed, 18 Aug 1999 14:25:49 -0400

<JC>
  BTW, I propose we use the phrases, "rooted at the URI"
vs "inherited at the URI/resource" when talking about
these locks.  As far as vocabulary goes, there are also
a few other cases that need vocabulary.  I'll save that
for a seperate note.
</JC>
<jra>
I don't know what either of these phrases mean. A resource is locked or
unlocked. A resource inherites any depth infinity lock of its parent collection,
no matter how it became a member of that collection.
</jra>
<JC>
As I said, I'll save the full vocabulary and lock/resource/URI
discussion for another note.  I'll
just say here that for discussing the differences between
the two proposals, we need terminology that describes
the situation where the two proposals differ.  The "Rooted"
phrase refers to that situation.  The situation where the
earlier LOCK request was originally (to simplify) at the
same URI that is now the destination of the MOVE.
</JC>

<jra>
I don't think the destination URL retains the lock of the resource that used to
be at that destination unless it just happens to have the same depth infinity
locked parent collection.
</jra>
<JC>
Right.  That's where there is a difference of opinion.
</JC>

<jra>
...But this would be a new lock with the timeout reset.
</jra>
<JC>
New lock?  Perhaps I didn't understand what you just said
above about "same.... parent".  Please run that by me again.
<JC>

---

From: [email-masked]
Date: Wed, 18 Aug 1999 14:45:46 -0400

From: Jason Crawford on 08/18/99 02:18 PM

To:   [email-masked]
cc:

Subject:  Re: LOCK Scenarios  (Document link not converted)

<jra>
I don't think the destination URL retains the lock of the resource that used to
be at that destination unless it just happens to have the same depth infinity
locked parent collection.
</jra>
<JC>
Right.  That's where there is a difference of opinion.
</JC>
<jra>
I hope I am expressing what is currently in the spec rather than an opinion. I'm
not opposed to changing the spec to something else, but I havn't seen anything
yet that would motivate me to retain destination locks.
</jra>

<jra>
...But this would be a new lock with the timeout reset.
</jra>
<JC>
New lock?  Perhaps I didn't understand what you just said
above about "same.... parent".  Please run that by me again.
<JC>
<jra>
Its a new lock on the destination (the new member of the parent collection), not
a new lock on the parent collection. Again, just like you would get if you did a
PUT or MKCOL to create a new resource in that collection. The new resource would
get a new (to it) lock inherited from its parent.
</jra>

---

From: "Yaron Goland (Exchange)" <[email-masked]>
Date: Thu, 19 Aug 1999 09:52:21 -0700

BTW when we originally discussed this in WebDAV the conclusion was that a
system like IE could handle the "merge" behavior on its own, without needing
any help from the server. That is, it could pipeline a bunch of copy's
w/overwrites. This wouldn't even hurt latency since the requests could be
pipelined.

However the reality is that things would probably be faster if there was a
way to say "Hey, merge." So why not just add a header which specifies merge
functionality? If you want to make sure it is honored then mark up with the
request with mandatory.

As for IE, sigh... I have forwarded the bug to the right folks but in the
meanwhile it might make sense to put in a detection for IE's user agent and
"do the right thing." I realize this sucks but bugs happen, especially
amongst early adopters.

		Yaron

> -----Original Message-----
> From: Kevin Wiggen [mailto:[email-masked]]
> Sent: Wednesday, August 18, 1999 3:56 PM
> To: [email-masked]; [email-masked]
> Subject: RE: LOCK Scenarios
> 
> 
> 
> OK not to make this any harder than it is....  But I have an 
> issue on the
> Webdav Issues list that a move/copy should not do the DELETE 
> by itself,
> ever.  This gives the client complete control and forces them 
> to do the
> delete before placing the file there.  This way my server is 
> not making any
> judgments about the existing resource for the user.
> 
> On a side note this has already been a complaint multiple times on
> Sharemation, and it has only been up for 2 days.  People think that a
> move/copy should be merging files, not overriding them.  
> Especially since IE
> is telling them its doing a merge!!!  And I quote "This folder already
> contains a folder named 'pictures'.  If the files in the 
> existing folder
> have the same name as files in the folder you are moving, they will be
> replaced.  Do you still want to move the folder?"
> 
> Now I am not saying we should do something because Microsoft 
> does it, but
> this is the behavior I would be expecting....
> 
> If you follow this train of thought, if I replace 1 file with 
> another, I
> would expect things like creation date to be left alone.  I 
> would expect
> that only the bytes would change.  From this I would expect 
> that any lock I
> had would still be there....
> 
> Maybe I am complicating things too much, but I just felt I 
> should mention
> it...
> 
> Kevin
>