Quoting Carsten Ziegeler <[EMAIL PROTECTED]>:
> > 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?
Yes, too late. IIRC you cannot set any headers when the OutputStream was been
written to.
> 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.
Sure, for convenience.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
