cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Russell <>
Subject Re: Sitemap mount concerns
Date Tue, 18 Jul 2000 15:31:31 GMT
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.

> 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. 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.

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

> 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

<map:match pattern="/foo">
	<map:mount src="./wibble.xmap">

Shouldn't the *visible* (not internal) name of the request from inside
wibble.xmap be '/bar/index'?

> And at the end I will suggest to move the sitemap internal <map:read>
> element to a <map:readers> section in the sitemap components (located
> in package org.apache.cocoon.reading :) to eliminate the (I think) last
> contract of the sitemap to the Environment. Remember a <map:read>
> implements a serializing generator. This will open the possibility to
> provide specific readers for specific needs. With this last change the
> sitemap is free from dealing with environment specific things except
> that the Environment object has to offer a method to set the "current
> directory" for the <map:mount> element.

Heh. Seems sensible. +1.

Cheers all,


Paul Russell                               <>
Technical Director,         
Luminas Ltd.

View raw message