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.

Yup.  I was being concise.  What you say is true.  I'm talking about legacy
systems or at least legacy expectations.  I didn't need to make the distinction
to express as much as I expressed.  You do to fully explain what you do below
though...


...


> > Now let's UNBIND  /url1.html

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

True.  I thought about this possibility after the note, but is likely to be the
implementation that we'll see?  Are we likely to actually see file names being
renamed (or copied) as a side effect of UNBIND?  Maybe, but this seems like a
bit of effort and it might cause problems for other parts of the system.
Anyway, we can consider this another approach and change my question a bit to
also ask if it is acceptable to have these servers rename the files as a result
of UNBIND requests.




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

I find seeing two lines dropping out of a resource to be a head scratcher.   I
guess you are meaning to say that a PUT on  /url1.html (or /url2.html)  then
both of the files get updated.  That's yet another proposal.  It would create a
bit of an odd situation if someone outside the protocol modified one of those
files though.  It's just another variant of my question to ask... "is THIS
option acceptable to folks?"

>  This is permitted behavior, and is in fact the only way to
> implement multiple variants of a single resource using a file system
> repository.
Depending on what you mean by "this" I may disagree with this statement.  My
note on variants showed how it could be done and it didn't *require* a trivial
syntactic mapping between URI's and filenames... as long as there was some
mapping function/table available.  Perhaps you feel this is outside the realm of
a file based server though.

>  One url is mapped to one resource, which is mapped to several
> files, one file per representation of the resource.
I guess it comes down to what we mean by mapped.  We probably agree, but I get
nervous when I see diagrams with two links coming out of the resource and
leading to something below.

> The benefit from a filesystem perspective is that /html/url2.html is only a
> hard link, not a copy.
For file systems that have hard links, that sounds like a very nice approach.  I
have noticed that some utilities break those links when you wouldn't expect it
though.  EMACS for one.


> 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'm curious what would happen to /html/url1.html.  Does that filename still
exist?
If so, the server needs a way to note which files should be ignored by the
server.  That's a different can of worms though.  Both approaches are variations
to consider.


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

Nice except for the EMACS caveat (which can be worked around) and the necessity
of a file system with hard links.   This option deserves further consideration.

J.

Received on Sunday, 2 May 1999 18:25:53 UTC