Re: Proposal: BIND method

"Geoffrey M. Clemm" wrote:

> 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".

Agreed.

> 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".

Right.

>    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"

Yes.  :-)

> If you mean "the client should be able to tell how the server
> implemented its bindings", then I disagree.

Nope, not trying to get into that--that was the point of BIND.  :-)

>    (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".

Whatever.  I didn't want take the time to come with a good term; I just wanted a
temporary...um, binding.  :-)

>    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).

Right.

--
/=============================================================\
|John Stracke    | My opinions are my own | S/MIME & HTML OK  |
|francis@ecal.com|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/

Received on Monday, 12 April 1999 17:35:36 UTC