- From: Jim Davis <jdavis@parc.xerox.com>
- Date: Wed, 3 Dec 1997 22:56:26 PST
- To: "ejw@ics.uci.edu" <ejw@ics.uci.edu>, "'WEBDAV WG'" <w3c-dist-auth@w3.org>
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