Re: Proposal: BIND method

"Slein, Judith A" wrote:

> What do HTTP servers currently do when they get a DELETE request?

Well, most say 501 Not Implemented.  :-)

> 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'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?

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

> If we rework the definition of DELETE, what impact does this have on the
> meaning of MOVE?

Ick.  Um...if I MOVE a...

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

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

--
/=============================================================\
|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 14:00:56 UTC