Re: Proposal: BIND method

   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