Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3CAB091D.22DCB906@apache.org>
Date: Wed, 03 Apr 2002 15:52:29 +0200
From: Stefano Mazzocchi <stefano@apache.org>
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [VOTE] (was: [RT]: Merging Stream And Event Pipeline)
References: <GMEBIBHGAOFGJCDPJANDAENHDPAA.cziegeler@s-und-n.de>
 <3CAAB142.2020301@anyware-tech.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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).

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org