- From: Anselm Baird_Smith <abaird@www43.inria.fr>
- Date: Thu, 3 Apr 1997 12:39:39 +0200 (MET DST)
- To: Alexandre Rafalovitch <arafalov@socs.uts.EDU.AU>
- Cc: "'www-jigsaw@w3.org'" <www-jigsaw@w3.org>
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.
[this is not the current implementation]
Joel, would this solve the problem ? Would that make anyone unhappy ?
Anselm.
Received on Thursday, 3 April 1997 05:42:05 UTC