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.
>
> 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.
>
> 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.
>
> 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.
Yes, you are right, we need a way to address this, but I really can't
find one.
I mean: having wildcarded hashmaps is something that I wouldn't know how
to algorithmically design.
Any idea?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
