- From: Geoffrey M. Clemm <gclemm@tantalum.atria.com>
- Date: Mon, 12 Apr 1999 17:22:36 -0400
- To: francis@ecal.com
- Cc: w3c-dist-auth@w3.org
From: John Stracke <francis@ecal.com> "Slein, Judith A" wrote: > Would we be asking servers to keep track of which bindings were created with > BIND and which were created in some other way (say with PUT), and interpret > DELETE differently depending on how the binding was created? In some cases, yes. For example, if the original resource is stored as a file, then the OS may not provide any suitable way to provide a link to that file that behaves correctly on DELETE. (Unix hard links will work, but only if both locations are on the same filesystem. Symbolic links, and their analogs in other OSes, won't work quite right because DELETE on the original will leave the links dangling; it would be necessary to replace one of the links with a copy of the original, and then update the other links.) Probably the only servers that can implement the two resources identically in all cases will be DMS-based servers which have an entry in their tables (or something) for each URI anyway. I interpreted Judy's question as "are there different protocol semantics for DELETE depending on how an advanced member collection was created". And the answer to that should be "no". The question John was answering (I believe) was "if a server implements some bindings differently from others, will it have to implement DELETE differently on some of those implementations than others". The answer to that of course is "yes". In particular, if it implements some bindings as just a file, and other bindings as symbolic links, then it has to do different things to those different implementations to maintain the *uniform* semantics of "a binding". I'm not sure how serious this is. Servers that support BIND-like functionality currently need some sort of way of keeping track of bindings for administrative purposes, don't they? Or just reject the BIND request, if they can't do the book-keeping. Oh, and, for efficiency's sake, it will probably always be desirable to be able to tell whether a resource is a link (the result of a BIND), because BIND on a link should create a link to the target, not to the existing link; otherwise you've got to chase through multiple links on each request. (Again, the exception is if you can use Unix hard links.) I assume you mean "the server should be able to tell how it has implemented its bindings" (I certainly *hope* that would be true :-). If you mean "the client should be able to tell how the server implemented its bindings", then I disagree. The protocol should support a single consistent definition of the semantics of methods when applied to advanced collection members. Different servers will play different games to implement these semantics, but those games should not be visible to the client, if we want to achieve interoperability. (Side note: I need a term for a URI which is either the result or the target of a BIND. I'll call it a polyvalent resource [one with multiple attachments]--clumsy, but I'm only writing one paragraph. :-) It might be more transparent (but perhaps even clumsier :-), if we just called it a "multibound resource". If I MOVE a polyvalent resource, I COPY it to the new URI and then DELETE it. The result is that the resource at the new URI is monovalent, not linked to the same resources as the original was. That would be a very *bad* definition of COPY (which you point out in your next sentence, but I wanted just to emphasize it :-). This is not necessarily what I really want; I probably want the resource at the new URI to be linked just as the original was. To get this behavior, MOVE on a polyvalent resource needs to be defined as a BIND followed by a DELETE. You'd have to weasle a bit with "is logically equivalent to", in order to allow the MOVE of a monobound advanced collection member to another server (if you really did a BIND/DELETE, the BIND would probably fail because of the inability to have cross-server bindings). Or you can invoke the magic "fixup" step of the original COPY definition. If you used the original COPY definition, and defined the fixup step to "change all the bindings to the old resource to be bound to the new resource", that works OK as well. To maximize clarity, I would advocate using both definitions in the advanced collection COPY definition. So a MOVE applied to an internal member of an advanced collection could be: A "MOVE source-URL target-URL" has the logical effect of a "BIND source-URL target-URL" followed by a "DELETE source-URL". This is logically equivalent to doing a "COPY source-URL target-URL", followed by a fixup stage that adjusts all the bindings to the source resource (except for source-URL) to be bindings to the new resource, followed by a "DELETE source-URL". I believe that John's formulation is sufficiently simpler/clearer than the "traditional" formulation, which is why I think it should be included. Cheers, Geoff
Received on Monday, 12 April 1999 17:24:57 UTC