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.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
