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, etc.) Giacomo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
