cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <>
Subject Re: Commentary (was Re: [Analysis] Cocoon, The Play)
Date Sat, 13 Apr 2002 12:13:53 GMT
On Fri, 12 Apr 2002, Berin Loritsch wrote:

> Berin Loritsch wrote:
> > Stefano Mazzocchi wrote:
> >>
> >> But I think Berin touches a few serious design issues
> >> (overcomponentization, role of cache control, component isolation) that
> >> we must seriously consider.
> >
> I think you also missed one of the points.  That is the current
> implementation of the Sitemap *pretends* to declarative when in
> fact it is truly procedural in the implementation.

We are free to have another implementation for it today as the Sitemap
is a component of type Processor.

> I think we should choose an approach for each type of Sitemap.
> Using my definition of Sitemap, we can have the current sitemap,
> the flowmap, or a proprietary map (nice place for a compiled
> Cocoon Block, eh?).
> I'm not saying it needs to be done for Cocoon 2.1, but soon.
> We should have a declarative sitemap, and a procedural one.
> One of the bottlenecks Cocoon has is the decision process, or the
> time spent in the sitemap.  With a declarative sitemap, we can
> have the equivalent of URL rewriting so that we can access the
> Reader info up front.

The Wyona CMS uses a nice approach I've never thought of by using a tree
of sitemaps. This way search time can be split up from a linear way to a
tree based way. Of course one has to do it by hand today.

> Currently, one way of optimizing the Sitemap is to place often
> requested things first.  I.e. your image matchers would perform
> better if placed first in the pipeline.  However, they look nicer
> when they are placed last.

Exactly, this can be done by a subsitemap because your images often have
their own URI space they live in. Placing a map:mount at the top of your
root sitemap doesn't clutter it up too much.

> We need a Sitemap that has a decision time that is fairly
> constant--as opposed to the length depending on the position
> in the sitemap.

I can see what you mean but also I see the concept of the Matcher
abstraction vanishing by that approach. For a speedup of search time one
needs to group Matchers of the same type (URIMatcher, TimeOfDayMatcher,


To unsubscribe, e-mail:
For additional commands, email:

View raw message