Re: Significant changes to protocol draft

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 03:00:55 UTC