cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@sundn.de>
Subject Re: [RT]: Session support
Date Thu, 18 Oct 2001 14:35:40 GMT
>
> Bernhard Huber wrote:
> >
> > Hi
> > > I still believe that serializers are somewhat special components and
> > > should not have a side entry for data.... also because I believe that
> > > serializers should be removed from pipeline definitions... but this is
> > > another story.
> > >
> > That would be great, as the request contains user-agent, and
> > the accepts http-header it should be possible to select
> > the correct serializer.
> > That way the serializer could be removed from the pipline defintion
> > completly.
> > Did I get it right?
>
> Well, I was thinking about internal content aggregation: since
> aggregation is going to be a major feature of Cocoon, I think that
> serializers should be added to adapt a pipeline to the external world,
> thus have a different semantic than today.
>
> So that doing something like this
>
>  [g -> t -> t] -> S
>
> where [...] is the pipeline allows you to do aggregation without the
> double serialization/deserialization (parsing) stages as we do today.
>
This is not true, the content aggregation uses sax streams and there
is no need for (re)parsing the parts.
More technical: Two pipelines: p1:[g1 -> t1 -> t2 -> s1] and p2:[g2 -> t3 ->
t4 -> s2]
and you want to aggregate them with [aggregate(p1, p2) -> t5 -> s3]
This results in:
[g1 -> t1 -> t2 \
                 > t5 -> s3
[g2 -> t3 -> t4 /

So the serializers of the aggregated parts are ignored.

Carsten
> Moreoever, it eases the concept of views since you can do
>
>  [g -(a)-> t1 -(b)-> t2 -(c)-> t3] -> S
>
> then the 'c' view of that URI
>
>  [c] -> [t -> S]
>
> is translated into
>
>  [g -> t1 -> t2 -> t] -> S
>
> and one could even aggregate different views without worring about
> serialization getting into its way.
>
> But this will requires some changes into the internal API since the
> cocoon:// protocol returns a byte stream not a SAX stream.
>
> So, lots of things to consider.
>
> Stefano.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


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


Mime
View raw message