A Short History of Copy and Move in WebDAV

In the beginning, a lone voice cried out "Copy is hard."

So the dialectic began (names have been changed to protect the guilty): 

Yaron: "If you copy a resource the result will be a perfect reproduction of
that resource."

Jim: "What does reproduction mean?"

Yaron: "Reproduction is a means for procreating the species, but that isn't
important right now. What is important is that the result of a COPY method
produce a resource which responds to each method exactly as the original."

Jim: "What if the source resource is a CGI file in the CGI directory and the
destination is not a CGI enabled directory? What if the source resource is
an ISAPI DLL and the destination is a JAVA resource?"

Yaron: "Um.... uh... um.... o.k. Um... lets... um... uh... ignore that part
of the problem. Yeah... yeah that's it! But at least the properties have to
be copied across exactly! After all, properties are useless if they don't at
least come across with the same behavior."

Jim: "Is interoperability served by having a copy fail because the source
and destination don't happen to support the same set of live properties?"

Yaron: "O.k. already, shesh, I give in! Best effort copy. You send in the
copy, you cross your fingers and you hope for the best. Maybe all the
methods work the same at the destination, maybe they don't. Maybe some
properties make it across, maybe some don't."

Jim: "The great wise man, Ted Hardie a.k.a. NASA Boy, has said that if a
client can not know what success and failure mean when executing a method
then the client will refuse to execute that method. Does your definition of
COPY meet Ted's requirement?"

Yaron: "Fair enough, we will define a 'pre-copy' method where you can get a
preview of the results of the copy."

Jim: "Won't that be expensive in terms of round trips? Will clients really
be able to do anything meaningful with the results? What will the expense be
if the copy is to use the depth header? Can you guarantee atomicity in terms
of the pre-copy and subsequent copy? Can your server implementation perform
the roll back after the pre-copy so as to ensure accurate results?"

Yaron: "So NASA Boy wants us to define how each method will operate at the
destination as a result of the copy?"

Jim: "I said he is a ***wise man***. He just means the properties."

Yaron: "But won't people figure out the executable resource problem?"

Jim: "People know about the problem, they just don't want to have to deal
with it."

Yaron: "Can we get away with leaving a gapping hole like that in the
specification?"

Jim: "You would be surprised with what we can get away with when a working
group want to side step an unsolvable problem."

Yaron: "O.k... so um... all properties MUST be copied across, but not all
may make it across as live properties."

Jim: "Let us pretend we have a versioned resource."

Yaron: "Pretend? But.. But.. I thought this was the Distributed Authoring
and Versioning Standard. Aren't we supposed to have versioning?"

Jim: "Shut up."

Yaron: "But..."

Jim: "SHUT UP. Now, as I was saying. Pretend we have a versioned resource
and lets pretend it has a version history property. Would you really want
the copy to succeed if the destination doesn't support the version history
property?"

Yaron: "Hum... I guess not. O.k. we will put in a switch that says that all
live properties must be copied across live and in case that is a little too
harsh we will also put in an option where you can specify that only certain
properties must be copied across live. The default will be best effort, live
if you can, dead if you must. Now clients at least know what the list of
properties at the destination will be and have some idea as to what their
value will be."

Jim: "Hum... perhaps today is a good day to die. SHIP IT!"

Received on Wednesday, 23 December 1998 17:49:35 UTC