Quoting Carsten Ziegeler <[EMAIL PROTECTED]>:
> > 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.)
This has to be done with great care. Think about sessions when doing redirects
that were not originated at the client. You might loose the session.
>
> 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.
You are absolutely right. Putting in new configuration possibilities mixes
concerns again. But the contract calling getContentLength() is somehow difficult
as it makes only sense to call it after the pipeline has been executed. And also
the responsability to cache the output is put down into the Serializer than. And
how can a Serializer determine if it should use a HoldingOutputStream instead of
the passed OutputStream if this decision is bound to the call at
getContentLength() (Chicken/Egg problem)?
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
