Re: DELETE in WebDAV Collections, URI to filename mappings, legacy servers

Just one minor terminological note. I'd like to make sure that we
don't confuse the concepts of mapping a URL to a resource with any
games the server may play in associating underlying files in the
file systems to a resource. In particular:
 From: Jim Whitehead <ejw@ics.uci.edu>
 /url1.html /url2.html
 | /
 | /
 resource "1"
 | \
 | \
 | \
 /html/url1.html /html/url2.html
 That is, have a one to many mapping of a resource to files in the
 filesystem. This is permitted behavior, and is in fact the only way to
 implement multiple variants of a single resource using a file system
 repository. One url is mapped to one resource, which is mapped to several
 files, one file per representation of the resource.
We could perhaps use a term "implements" instead of "mapping", i.e.:
"That is, a resource can be implemented by several files in the
filesystem. This is permitted behavior, and is in fact the only way to
implement multiple variants of a single resource using a file system
repository. One url is mapped to one resource, which is implemented by
several files, one file per representation of the resource."
 The benefit from a filesystem perspective is that /html/url2.html is only a
 hard link, not a copy.
 Now, when an UNBIND occurs, the picture changes to:
		 /url2.html
		 /
		 /
 resource "1"
		 \
		 \
		 \
		 /html/url2.html
 Now, admittedly, this behavior causes problems for those proposed
 definitions of UNBIND which prevented state changes on the server,
 suggesting those definitions may need some tweaking...
I don't think that the proposed definitions (or at least, my proposed
definition :-) of UNBIND prevented state changes on the server. To the
contrary, it explicitly *avoids* saying anything about state changes
on the server beyond the change to the advanced collection from which
the binding was removed.
Cheers,
Geoff

Received on Saturday, 1 May 1999 23:45:19 UTC

AltStyle によって変換されたページ (->オリジナル) /