W3C home > Mailing lists > Public > www-jigsaw@w3.org > March to April 1997

Re: More digging.

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>
Message-ID: <Pine.LNX.3.95.970406134958.253C-100000@asmodeus>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 9 April 2012 12:13:26 GMT