cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: [C3] Caching
Date Tue, 23 Dec 2008 12:43:03 GMT

Steven Dolg wrote:
> Actually that is all we have right now.
> Pipeline and PipelineComponent. With PipelineComponent being
> differentiated into Starter, Finisher and Consumer/Producer - what you
> called the "middle parts". (Actually there is still a design flaw: the
> consumer is no PipelineComponent, but that'll be corrected presently).
> Consumer and Producer are separated into two interfaces, as to not
> require special handling when linking the Starter with the second
> component or the second to last with the Finisher.
> I like to call these the "structural layer", because they define the
> structure of any pipeline:
>    * first component is always a "Starter"
>    * last component is always a "Finisher"
>    * any number pairs of "Producer"/"Consumer" between them
> Every (valid) pipeline is composed in this way - regardless of what
> content or which implementation.
> Thus these interfaces have no relation to anything that is content-based.
> But that's also why we need additional layers, because otherwise the
> pipeline would be specific for every type of content (which it should not)
I like the explaination :) Yes, it makes sense this way.

> All the XML... interfaces are already the "content layer" (in this case
> for SAX) on top of the "strcutural layer"
> It defines how the components communicate with each other:
>    1. XMLConsumer is a ContentHandler and LexicalHandler
>    2. XMLProducer can accept an XMLConsumer and provide it with
> appropriate data
> Follow (basically) by AbstractXMLProducer (implementation of 2. from
> above) and AbstractTransformer (AbstractXMLProducer + XMLConsumer).
> The "content layer" is already beyond the scope of the Pipeline API
> module - it does not care about this at all.
> This is solely the domain of the pipeline components.
> That's why the SAX layer should be removed asap from the Pipeline API.

> <SNIP/>
> Absolutely!
> With two types of XML components (SAX, StAX) this name is completely
> ambiguous and must be changed (I prefer SaxConsumer).
> This would also emphasize that the Pipeline API is designed to be
> content-agnostic and SAX is merely one type of content it can handle.
> StAX is the first step to add another content-type - well it's still
> XML, but works completely different.

> Not at all - I usually welcome all input!
> I just have a hard time, when I struggle to get the actual point.
> Trying to understand what you mean, I looked at some code and followed
> the class/interface hierarchy.
> And while doing so I found that some of this is rather strange and took
> me moment to sort out.
> And I think I know now what you mean.
Yes, it's hard to explain (at least for me) :)

> But I guess it's mostly a problem with the names of the
> classes/interfaces (like "AbstractTransformer" being actually an SAX
> based Producer/Consumer) and mixing SAX with the Pipeline.
> I suppose separating those two and changing some of the names it should
> be alot better.
Yes, I guess that's all we have to do.

>>  It's
>> just about minor improvements if at all.
> I think it's actually a little bit more than that.
> Seems like I was already so accustomed to the concept in my head that I
> didn't even see, the implementation has become less clear that it could be.
This happens, but here we have the advantage of the community :)

> So PLEASE keep on doing this!
> And don't feel bad when my answers appear a little harsh - I rarely mean
> it that way... ;-)
No problem with that :)


Carsten Ziegeler

View raw message