[EMAIL PROTECTED] wrote:
> Hello,
>
> are there any thoughts about a parallel version of content-aggregation ?
> It would be fine to know something about the pro, cons, and future plans
> or if help is needed ;^)
What you are refering to is a very complex beast--especially when it comes
to ordering the SAX events. For instance, let's assume we have the following
structure:
<map:aggregate>
<map:part src="cocoon://foo.xml"/>
<map:part src="cocoon://bar.xml"/>
<map:part src="cocoon://baz.xml"/>
</map:aggregate>
The aggregation engine would be receiving SAX events from all three pipelines
simultaneously. As a result the start and end element tags would be intermixed.
this is clearly bad. The alternative is to cache the results of the sub pipelines
until they are needed. However, the current cache mechanism already does this!
So the only REAL benefit will be on the first access to the resource in question.
Concidering all the complexities involved, the synchronization issues, and the
overhead of threads (since we already have to use one thread per connection);
the effort involved to buy what is in essence 10-20ms/part[2+] really isn't worth
it. In the above example, the first part doesn't save any time, but the second
two may. In essence the overall speed benefit will be 20-40ms. Even then, I
am estimating that it would be closer to only 20ms. Especially if the second part
is shorter than the first part!
Beleive me, I thought about this in detail. I just don't see how the benefit
outweighs the costs.
--
"Those who would trade liberty for
temporary security deserve neither"
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
