RE: LOCK Scenarios

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:wiggs@wiggenout.com]
> Sent: Wednesday, August 18, 1999 3:56 PM
> To: jamsden@us.ibm.com; w3c-dist-auth@w3.org
> 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
>

Received on Thursday, 19 August 1999 12:52:29 UTC