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

> I just want to point out something that you might have already discussed.
> It's just that the URI to filename mappings can get unintuitive... even if
> the server doesn't have versioning support.
>
>    Let's start with the following configuration and let's assume a file
> based server...
>
>
>  /url1.html     (url segments)
>   |
>  /html/url1.html    (resources... aka filenames)

A resource is not "also known as a filename", it is an abstraction which
*may* be mapped to a file via a filename.

So, I'd draw your picture:

 /url1.html     (url segments)
   |
 resource "1"   ("1" is just some arbitrary identifier, known only to the
server,
   |             and many servers will not physically instantiate the
resource,
   |             or its identifier.  It's an abstraction.)
   |
 /html/url1.html  (filename for the persistent state of resource "1".

>
>
> Now lets bind /url2 to the resource we have there
>
>  /url1.html    /url2.html   (url segments)
>       |         /
>       |       /
>       |     /
>  /html/url1.html    (resources... aka filenames)

I'd draw this:

  /url1.html    /url2.html
        |         /
        |        /
        |       /
     resource "1"
           |
           |
     /html/url1.html


> Now let's UNBIND  /url1.html
>
>              /url2.html   (url segments)
>                /
>              /
>            /
>  /html/url1.html    (resources... aka filenames)

OK, here's where we start to diverge:

              /url2.html
                  /
                 /
                /
     resource "1"
           |
           |
     /html/url2.html


That is, the binding of URL to resource *stays the same*, but that doesn't
mean the mapping from resource to filename has to remain the same.


> Now let's do a PUT on /url1.html
>
> /url1.html             /url2.html   (url segments)
>   |                      /
>   |                    /
>   |                  /
> xxxx.html     /html/url1.html    (resources... aka filenames)

Now your problem disappears:

  /url1.html              /url2.html
    |                      /
    |                     /
    |                    /
  resource "2"       resource "1"
    |                    |
    |                    |
  /html/url1.html    /html/url2.html


An alternate way of looking at this which has benefits for filesystem
implementations is this:

Start with:

 /url1.html
   |
   |
 resource "1"
   |
   |
 /html/url1.html

Make the binding:

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

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

From the filesystem implementation perspective, the benefit is now you have
the filesystem doing your consistency maintenance for you, and the
implementation can get away with having no physical instantiation of
resource "1" (or any resource).

- Jim

Received on Saturday, 1 May 1999 19:08:57 UTC