- From: <ccjason@us.ibm.com>
- Date: Sun, 2 May 1999 18:13:07 -0400
- To: w3c-dist-auth@w3.org
> > 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