cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <Giacomo.P...@pwr.ch>
Subject Re: Sitemap mount concerns
Date Tue, 18 Jul 2000 18:48:26 GMT
Paul Russell wrote:
> 
> hi all,
> 
> > 1. Make sub sitemap generation/compilation/instantiation/initialisation
> >    at run time.
> > 2. Make a separate <map:mounts> section restricting the src= attribute
> >    values to a fixed path and add an additional uri-prefix= attribute
> >    which specifies what its name implies (prefix of the uri the sub
> >    sitemap is mapped to).
> 
> Personally I much prefer the first option, although we should attempt
> to optimise this as much as possible.

Can you explain why?

> > Consequences of
> > 1. If the sitemap encounters a <map:mount> for the first time and thus
> >    has no "old" sub sitemap to use during asynchronious sitemap
> >    generation, it has to report an "unavailable error" to requestors or
> >    do the generation of the sitemap synchroniously and delay the
> > request
> >    until generation is finished. In every other case even if the
> > sitemap
> >    has changed there is still an old sitemap object to use until the
> >    generation of the changed sitemap is ready to take control.
> > 2. This approach is less flexible but would garantee to have a
> >    responsive system after startup because all sitemaps could be
> >    generated at startup time. Requests to a starting cocoon system
> > would
> >    be automatically queued by the servlet engine.
> 
> Can I suggest a hybrid approach? Have the sitemaps mounted and compiled
> at runtime, but have an agent which maintains them at runtime. 

The sitemap itself maintains all sitemaps!

> This way,
> we start the engine (and the agent), and the agent starts traversing the
> root sitemap (or potentially a dummy mountpoint) looking for mountpoints.
> If it discovers one which isn't parameterised, it should start an async-
> ronous generation thread to build that sitemap and then continue to
> traverse. This gives us the best of both worlds - a system which is up
> and operating ASAP combined with the flexibility of the first solution.

I think you missed the point. Sitemaps _are_ maintained at run time. I'm
using the following terms: "run time" or "request time" means the state
when cocoon is ready to process requests; "init time" or "config time"
means the state when cocoon starts and maybe generates, compiles and
instanciates the sitemap, instatiates and configures the sitemap
components (generators, serializers, etc).

You should read Stefano's "Cocoon Hackaton #1". Everything stated under
"Sitemap Generation" is set. But I've only some little troubles with
implementing some details not mentioned there. Changed sitemaps are
regenerated asynchroniously and if there is an old sitemap object this
is used until the new one is ready to take over. If there isnt a sitemap
already in use then we have to delay the request [this remembers me to
have a thread concerning error handling later on].

> If a client requests a sitemap which is still being generated (or has not
> yet been traversed), then my preference is to block the request thread
> - I don't think we should be returning errors on non-exceptional
> conditions.
>
> > The notation of a uri-prefix itself would also solve the problem of
> > telling the Environment object at which "current directory" in the uri
> > space it is when chaining to sub sitemaps (remember we said that sub
> > sitemaps have no notion of where in the uri space they are mounted on
> > from the view of a sitemap maintainer). Otherwise the <map:mount>
> > element has to deal with the request.getUri() and the match of a
> > possibly not available uri-matcher to find out the prefix to advance in
> > the uri space for a sub sitemap. Because the mount element is an
> > internal component of the sitemap as apposed to the sitemap components
> > like generators, serializers, etc, this has the benefit that the mount
> > element doesn't have to deal with environment specific things like
> > 'environment.getRequest().getUri()'. This would eliminate another
> > contract to the calling environment. <map:mount> only has to tell the
> > Environment that from now on it has to advance to the uri-prefix
> > position in the uri space for subsequent requests of components to the
> > uri in sub sitemaps.
> 
> Err - shouldn't we be transforming the uri into the (uri) namespace of
> each sitemap? For example with the url "/foo/bar/index", and the sitemap
> chunk:
> 
> <map:match pattern="/foo">
>         <map:mount src="./wibble.xmap">
> </map:match>
> 
> Shouldn't the *visible* (not internal) name of the request from inside
> wibble.xmap be '/bar/index'?

Correct. But it shouldn't be the sitemap itself dealing with the uri.
Instead the Environment, which serves the uri to all components should
be informed of what to strip off for succeding calls to getUri() from
components in sub sitemaps. Suggest the following definition

    public interface Environment {
        public void addUriPrefix (String prefix);
        public String getView ();
        public String getUri ();
    }

The interface above is all a sitemap must know about the calling
environment. If the <map:mount> element doesn't know the uri-prefix it
has to set for mounted sub sitemaps (from its configuration in the
sitemap) it has to examine it itself. To be able to do this, it must
hope the surrounding <map:match> element has put some replacements from
the wildcards into the Map, that matchers usualy return, to find out the
right prefix the Environment has to strip off the uri for components in
sub sitemaps. But this behaviour cannot be garanteed.

If we go with possibility 2 the <map:mount> element doesn't even have to
get an uri and so the third method is not used by the sitemap itself (of
course sitemap components should be able to use this method _only_ to
get the current uri).

Now you can extend it to a specific environment like

    public interface HttpEnvironment implements Environment {
        public HttpRequest getRequest ();
        public HttpResponse getResponse ();
    }

and sitemap components (which generally will be environment specific)
can make use of the extended interface. To be specific those returned
objects (HttpRequest and HttpRespons) should be extended to protect
methods like getOutputStream, getWriter, etc.

Giacomo

-- 
PWR GmbH, Organisation & Entwicklung      Tel:   +41 (0)1 856 2202
Giacomo Pati, CTO/CEO                     Fax:   +41 (0)1 856 2201
Hintereichenstrasse 7                     Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen                    Web:   http://www.pwr.ch

Mime
View raw message