cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@sundn.de>
Subject AW: [C2]: Proposal for intermediate output stream
Date Mon, 09 Jul 2001 06:38:22 GMT
> Giacomo Pati wrote:
>
> On Thu, 5 Jul 2001, Carsten Ziegeler wrote:
>
> > Hi,
> >
> > I am currently thinking since some weeks of the following enhancement:
> >
> > Creating an intermediate output stream for the response and not directly
> > writing to the output stream of the servlet engine (or the environment).
> >
> > This would solve the following problems:
> > 1. The output stream can be reset at any time, making
> redirections possible
> >    at every stage (although I personally don't like this, but
> there seems
> >    to be a great demand for it)
> > 2. When the error pipeline is called due to any exception etc,
> the output
> >    stream should be reset as a new error generator starts producing new
> >    output. If accidentally something was already written to the output
> >    stream, you get a confusing response.
> > 3. The special cocoon urls can currently not be used everywhere, e.g.
> >    inside a map:redirect-to statement. We could solve this by resetting
> >    the intermediate output stream and start on the server a new
> >    generation process without returning to the client.
> > 4. The content length of each response can be determined. This seems
> >    to be important for the pdf generation (see the corresponding thread
> >    on the user list).
> >
> > The only disadvante I see currently is some loss of performance.
> >
> > Comments? Critics? Suggestions? Wishes?
>
> The loss of performance is critical IMHO. One possible solution might be
> to augment the serializer element with an attribute interpretedby the
> sitemap engine (lets call it set-conten-length="true|false"). As the
> sitemap engine is the one that gives the OutputStream to the serializer
> an HoldingOutputStream could be craeted by the sitemap engine and given
> the objectModel to set the content length prior to really write the
> collected output to the real OutputStream. Hnestly, I don't know if this
> approach fits into the caching system.
>
> This way you have the performance loss only on serializer with the
> attribute mentioned above.
>
Ok, I am not sure if an intermediate output stream is really such a hugh
performance loss, but it might be.
So, I listed 4 points above. We could fix them in the following ways:
1. Can be neglected as it is not necessary to make a redirect at any time.
   And I think it is bad style anyway. So, put it simple: solved.

2. I see to working solution for the error pipeline right now.

3. Using any urls in redirects. We could either forbid this or we could
   make some changes to the engine which would result in performing the
   redirect directly on the server. As at the stage of an redirect nothing
   is written to the output stream the engine could simply call itself
   with the new url (actually, this sounds easier as it is, but I think
   it should work.)

4. As the contentLength is only required for the pdf generation I think
   we should go with a Giacomo's proposal with a slight modification.
   I don't like the idea of configuring the behaviour of the serializer
   myself. It is great to have the possibility but it should work
   without any handwork in the sitemap.
   Adding a getContentLength() to the serializer interface and changing
   the behaviour of the fop serializer that it returns the correct
   content length. All other serializers simply return -1 for indicating
   that they don't now the length.
   If it is really required we could at later the configuration of the
   serializers.

So, I think the only thing we should think of is point 3.


Carsten

Open Source Group                        sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de                          mailto: cziegeler@sundn.de
================================================================

> Giacomo
>
>
> ---------------------------------------------------------------------
> 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