> Giacomo Pati wrote:
>
> 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.
>
I think if we simply use the same mechanism as for the cocoon urls this
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.
>
> 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)?
>
Hm, this is more difficult than I thought of. Ok, looking at the readers
they are implemented in a similar way: the generate() method is invoked
which generates the content and it returns the real content length
or -1. The stream pipeline and the caching system are taking care of
this.
With the serializer it could be the same: The serializer itself knows
how to handle the output: it knows if he should count the bytes
or not. After the processing is finished the stream pipeline asks the
serializer for the content length and sets it accordingly. Or might
this be too late? I thought of (and forgot to mention) a
CountingOutputStream
which could be used by the serializer. This output stream counts only the
passed in bytes and forwards all events to the real output stream.
Carsten
>
> Giacomo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
