Re: Significant changes to protocol draft

Marc,

I apologies for not conveying my point  more clearly. What I was arguing
earlier, was that just as in the world of Physics, there is no
"preferred state" of rest or motion, as all motion is relative, in HTTP
world, there are no "preferred semantics" to method names. Hence there
is really nothing holy about "COPY" or "MOVE" or "LOCK" or "UNLOCK",
since they may mean something in English, they probably don't mean
anything in Chinese, or Japanese. So if I were to propose the method
name "HATAO" instead of "MOVE", because it means something in some
non-English language, at any stage of WEBDAV design (that is
irrelevant), would you have an objection to it, only because it does not
carry the semantics of "MOVE" which you are more familiar with. That is
what I meant when I argued that in HTTP paradigm, method names are
opaque tokens with no real meaning attached to them.

Having said all that, I am still open to withdrawing my proposal, if for
some sentimental reasons, there is general dissent in WEBDAV community.

Asad Faizi
-----------------------------------------------------------------------------------------

Marc Eaddy wrote:

> Asad,
>
>
>
> \\Marc Eaddy
>
> At 10:56 AM 12/4/97 -0800, you wrote:
> >The proposal to change the name of the these methods was put by me in
>
> >the last DAV Design meeting, and accepted graciously by fellow
> designers
> >from Microsoft, Novell, and our chair Jim Whitehead, with a an
> >undestanding that, in HTTP paradigm, method names are mere opaque
> tokens
> >and has no real meaning attached to them (case in point POST), and
> are
> >the most insignificant part of the design exercise, specially for
> those
> >who are "DOING THE RIGHT THING" by not implementing anything till the
>
> >spec finalizes.
> >
> >It is not a technical issue, not even a matter of backwards
> >compatability for Netscape, since there are many ways to implement
> DAV
> >with or without names conflicting with previous versions of
> Netscape's
> >Web Publishing servers. It only makes it cleaner for people to
> implement
> >it both on the server and client sides, with almost no cost or impact
> to
> >WEBDAV design.
> >
> >Having said that, the last thing Netscape wants to do is try to shove
>
> >anything down the throat of WEBDAV community. As much as I believe
> that
> >method names are completely insignificant, opaque tokens, with no
> real
> >meaning attached, if there is general dissent in WEBDAV community, I
> am
> >very much willing to withdraw my proposal. Believe me this will not
> make
> >or break Netscape.
> >
> >As far as hitting the roof is concerned, I don't know about that. I
> >don't recall hitting the roof anytime Microsoft proposes changes to
> the
> >design which have far bigger impacts on WEBDAV than some method name
> >changes. Now,  when they start messing with the Java Virtual
> Machine!!!
> >that's when I hit the roof  (same to you Yaron)  ;-))
> >
> >Asad Faizi
> >----------
> ------------------------------------------------------------------------
>
> >
> >Jim Davis wrote:
> >
> >> At 02:29 PM 11/25/97 PDT, Jim Whitehead wrote:
> >> >...[a forthcoming change in v6]
> >>
> >> >6. Rename methods:
> >> >   COPY -> DUP, MOVE -> RENAME, LOCK ->RESERVE, UNLOCK ->
> UNRESERVE.
> >> >
> >> >The rationale for this change is to avoid a method name conflict
> with
> >>
> >> >versions 2 and 3 of the Netscape Enterprise Server which contained
>
> >> >prototype versions of these methods. This change will take effect
> in
> >> the
> >> >-06 specification.
> >>
> >> I personally do not see this as a compelling rationale.  I offer
> two
> >> arguments:
> >>
> >> 1. The current method names seem like the most appropriate ones,
> given
> >> the
> >> functionality, while the new names seem less intuitive.
> >>
> >> I know that names are totally arbitrary, and we could just call the
>
> >> methods
> >> FOO, BAR, BAZ, and QUUX (indeed, it would be pleasing to old Lisp
> >> hackers)
> >> but having meaningful names does seem like a good thing.
> >>
> >> Consider MOVE.  I can easily explain to someone that when you MOVE
> >> something, e.g. from one collection to another, or one server to
> >> another,
> >> you take it out of the old one and put it into a new one.  It is
> less
> >> clear
> >> how to explain RENAME in that way.
> >>
> >> As for LOCK and UNLOCK, these are exactly the right names, given
> the
> >> analogy with locking in a file system.
> >>
> >> If you really have to change the name, perhaps PROTECT AND
> UNPROTECT
> >> would
> >> be better?
> >>
> >> RESERVE seems bad to me.  To RESERVE is to set aside for later use.
>
> >> We
> >> RESERVE  space (e.g. bits are reserved for future expansion,
> parkland
> >> is
> >> reserved for nature and/or drilling, books on reserve may be read,
> but
> >> not
> >> removed.)  Also,  in at least some versioning systems, RESERVE has
> the
> >>
> >> sense of claiming the right to make the next version of a thing.
> And
> >> frankly, a "shared reservation" sounds like, well, where the US
> >> government
> >> forces native people to live or something.  In any case, you should
>
> >> ask,
> >> say, the folks at MKS, or some other versioning system, whether
> *they*
> >> have
> >> a Web server that already uses RESERVE in some uh, "reserved" way.
> >>
> >> In any case, if you change them, are you also going to change the
> >> Lock-Token header and the opaquelocktoken scheme accordingly?
> >>
> >> As for DUP, it's not even a word.  "DUPE" is a word, but it has
> >> unfortunate
> >> connotations of deception and fraud.
> >>
> >> 2. It's a bad precedent.
> >>
> >> While your explanation was not very detailed, it seems like you are
>
> >> saying
> >> that Netscape implemented an early version of DAV, and the
> >> implementation
> >> defines methods such as LOCK with semantics incompatible with those
> of
> >>
> >> modern DAV.  Is that right?
> >>
> >> But so what?  Surely their implementation differs in many, many
> ways
> >> from
> >> the modern form of DAV, not just in these four methods.  There's no
>
> >> way
> >> that a DAV client is going to interoperate with both the Netscape
> >> server as
> >> it is and the reference (Jigsaw) DAV server, even if we change
> those
> >> four
> >> names.
> >>
> >> The bad precedent is allowing someone to implement an early version
> of
> >> a
> >> spec *while it's being designed* and then have them ask the spec to
>
> >> stop
> >> changing (or change in otherwise undesirable ways) for the sake of
> >> compatibility with the early version.  It's one thing if early
> >> adopters
> >> come back and say "look, we've already tried this idea, and can
> tell
> >> you
> >> it's full of problems".  It's another to say "Don't do this, it
> will
> >> make
> >> our customers unhappy".  Early adopters go to market early and take
>
> >> risks.
> >> They shouldn't get any extra voice in defining the spec for that
> >> reason
> >> though.
> >>
> >> I tell you honestly, if it was Microsoft asking for this, I would
> have
> >> hit
> >> the roof, so it seems only fair to hold Netscape up to the same
> >> standard.
> >>
> >> If, on the other hand, I've misunderstood the rationale, I ask that
>
> >> someone
> >> explain it a little better, and not flame me.  I can only go on
> what's
> >>
> >> stated in the email.
> >>
> >> Best regards, (and certainly no malice intended, and I hope, none
> >> taken.)
> >>
> >> Jim
> >>
> >> ------------------------------------
> >> http://www.parc.xerox.com/jdavis/
> >> 650-812-4301
> >
> >
> >
> >
> >

Received on Thursday, 4 December 1997 15:25:16 UTC