- 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