- From: Joel Crisp <joel@asmodeus.demon.co.uk>
- Date: Sun, 6 Apr 1997 13:56:35 +0100 (BST)
- To: Anselm Baird_Smith <abaird@www43.inria.fr>
- cc: Alexandre Rafalovitch <arafalov@socs.uts.edu.au>, "'www-jigsaw@w3.org'" <www-jigsaw@w3.org>
Hi Only just got to look at this. Comments interleaved. Joel --- joel@asmodeus.demon.co.uk | "I remember Babylon" - Arthur C Clark Cynicism, sarcasm, psychosis | On Thu, 3 Apr 1997, Anselm Baird_Smith wrote: > Alexandre Rafalovitch writes: > > On Thu, 3 Apr 1997, Anselm Baird_Smith wrote: > > > > > > > > That's for LookupState, now the problem for consuming is rather > > > located in the COntainerResource (which of peek/get Component it > > > calls). The issue (related to ContainerResource) is still open.. > > > > > > > I am lost now. Why is consuming now in ContainerResource? I thought > > it was in LookupState, so that filters and others could also consume > > it/modify it. Can you explain what you modified? Or was it just awkward > > wording? > > I guess (hope) it's awkward wording. > > LookupState provides access to the URL, it allows you to peek (lookat) > and get (consume) "components" of the path. That's its purpose. > > ContainerResource, HTTPResource and ResourceFilter are the one that > actually do the lookup. How they interact with LookupState > wether/when they call {peek/get}Component defines that interaction. My > understanding is that that interaction is at best underspecified, and > probably inconsistent. Here is one (possible) specification: > > A container resource must only consume the parts of the path it can > resolve. It must leave in LookupState any parts it cannot resolve. If I understand you correctly, this will not work if you have to back up the tree. If a resource resolves and consumes part of the URL, but then the lookup fails further down the tree, you can not back up past the resolved resources. For example, suppose I have a resource which is aware of several alternative remote sites. I ask for a resource held by it, and it interrogates a remote site resource contained within. That particular remote site does not have the requested resource, so you have to back up past the _resolved_ remote site to try a different one. MyResource | ----RemoteResource(1)---Document(1) | | | --Document(2) ----RemoteResource(2)---Document(1) Copy(2) | --Document(3) Here, a search for document 3 could resolve the path to RemoteResource(1), but then has to back up over it when RemoteResource(1) fails to resolve Document(3). Does this make sense ? > > [this is not the current implementation] > Joel, would this solve the problem ? Would that make anyone unhappy ? > > Anselm. > > Joel
Received on Sunday, 6 April 1997 09:34:43 UTC