cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <>
Subject Re: [VOTE] (was: [RT]: Merging Stream And Event Pipeline)
Date Wed, 03 Apr 2002 19:22:21 GMT

Thanks for pointing it out again.


On Wed, 3 Apr 2002, Stefano Mazzocchi wrote:

> Sylvain Wallez wrote:
> > Yeah, I know Stefano doesn't like that, but so many people feel the need
> > for it... So Stefano, if you don't like that, please give us a cool
> > explanation like the one you gave for "views from last label". IIRC this
> > has to do with cacheability, but CachingStreamPipeline has some
> > provision for cacheable serializers. So ?
> When I designed the pipelines for Cocoon2, I thought about serializers
> as a mix between a 'facade' and an 'adapter': pipelines are SAX based,
> but the world is octet based, so we needed a way to 'adapt' between the
> two.
> In this regard, the serializer is a commodity. In theory, is not even
> part of the pipeline, but it's the final step to 'adapt the result to
> the outside world'. Some serializers, then became more complex and
> performed juicy functionalities, but only to 'adapt' to other worlds
> (PDF or JPG for clients unable to handle FO or SVG directly).
> Now, if you think as serializers as 'wrappers' of SAX output, you also
> understand why 'internal pipelines' don't need them and you also
> understand why 'pipeline views' need serializers as well.
> But you also understand why I don't want serializers to be regular
> sitemap components: because they should *not* change the result of the
> pipeline, they are just adapters!!!!
> Now: if we *design* serializers *not* to mess with the content of the
> stream, just to 'adapt' it to some other world, we don't need to make
> the caches aware of them!!! because, from the caching perspective,
> having an FO document or the translated PDF doesn't matter if the
> 'serializing behavior' can be considered unchangeable.
> So, I still remain -1 on this also because it forces people to think
> differenently and factor-out the logic that requires access to the rest
> of the pipeline components into a transformer and place that *before*
> the serializer.
> This makes it also possible to 'reuse' that refactored logic outside of
> the serializer.
> So I remain -1 until one exposes me with an example that it can't be
> refactored in such a way (or it is more elegant *not* to refactor it in
> such a way).

To unsubscribe, e-mail:
For additional commands, email:

View raw message