You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@sundn.de> on 2001/07/05 14:49:28 UTC
[C2]: Proposal for intermediate output stream
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?
Carsten
Open Source Group sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto: cziegeler@sundn.de
================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Proposal for intermediate output stream
Posted by "Piroumian, Konstantin" <KP...@flagship.ru>.
> 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.
If I get you right, this will enable RequestDispatcher.forward()/include()
like behavior in sitemap, right? That would be great. This will also enable
to use Cocoon as a controller servlet, e.g. with pure JSP pages (not from
JSPGenerator): some actions could be performed in the pipeline, say, request
data processing, etc. and the request could be forwarded to a JSP page to
view the data in a form, etc. In the current implementation it's possible
only with redirect, which is not my favourite way of flow control.
> 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?
Just some thoughts about what can be the "minimal Cocoon" and "typical
Cocoon". Currently, I don't use any XSP, SVG, PDF, etc. in C2 - it's used
only as a screenflow controller servlet (like in Model - View - Controller
design pattern). The pages are in JSP (don't ask me why, I am not the author
of this design) and we need only to control their sequence. So, with forward
and include capabilities in sitemap the "minimal Cocoon" could be only the
servlet and engine, which are necessary for sitemap processing, without
anything else, including XSP. So, after installing the "minimal Cocoon" the
developer can add pipelines, matchers, actions, views, resources, which are
necessary for his application only.
"Typical Cocoon" could be a "typical" set of generators, transformers,
serializers and maybe selectors, which are used in most of the Cocoon based
applications.
And, at last, "full Cocoon" could be a full set of everything in Cocoon,
including samples.
Additionally, can be an option for installing 3rd party tools, like the
sitemap editor, or so.
Sorry, for a little off-topic comments.
>
>
> Carsten
>
Regards,
Konstantin Piroumian.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [C2]: Proposal for intermediate output stream
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Donald Ball wrote:
>
> On Thu, 5 Jul 2001, Sergio Carvalho wrote:
>
> > Wouldn't this break streaming? i.e. producing output even when only
> > part of the result has been processed? Streaming buys you some
> > processing time if you have 'heavy' pages, but still want to follow
> > the rule of thumb of producing some feedback in under 3s and the whole
> > page in 7s.
>
> that's why it should be configurable. but when you're producing lots of
> responses in short amounts of time, it makes sense to buffer them and set
> the content length on the response so that the client can continue to use
> the same http session instead of having to open a new one for each
> resource. right? or is it the case that if a resource is cached, the
> content length will be set on all subsequent responses?
>
Yes, it is. For a completly cached response the content length is always
set.
Carsten
> - donald
>
>
> ---------------------------------------------------------------------
> 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
Re: [C2]: Proposal for intermediate output stream
Posted by Donald Ball <ba...@webslingerZ.com>.
On Thu, 5 Jul 2001, Sergio Carvalho wrote:
> Wouldn't this break streaming? i.e. producing output even when only
> part of the result has been processed? Streaming buys you some
> processing time if you have 'heavy' pages, but still want to follow
> the rule of thumb of producing some feedback in under 3s and the whole
> page in 7s.
that's why it should be configurable. but when you're producing lots of
responses in short amounts of time, it makes sense to buffer them and set
the content length on the response so that the client can continue to use
the same http session instead of having to open a new one for each
resource. right? or is it the case that if a resource is cached, the
content length will be set on all subsequent responses?
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Proposal for intermediate output stream
Posted by Sergio Carvalho <se...@acm.org>.
On Thu, 5 Jul 2001 14:49:28 +0200, "Carsten Ziegeler" <cz...@sundn.de> 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?
Wouldn't this break streaming? i.e. producing output even when only part of the result has been processed? Streaming buys you some processing time if you have 'heavy' pages, but still want to follow the rule of thumb of producing some feedback in under 3s and the whole page in 7s.
--
Sergio Carvalho
---------------
sergio.carvalho@acm.org
If at first you don't succeed, skydiving is not for you
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [C2]: Proposal for intermediate output stream
Posted by Vadim Gritsenko <vg...@hns.com>.
I also think that should be configurable feature.
+1 if it's configurable,
+10 if it's configurable per <map:pipeline>
PS: I do remember somebody wanted "streaming" behaviour for cocoon, i.e. cocoon outputs
result when generation is not finished yet. We should keep this ability.
Vadim
> -----Original Message-----
> From: Torsten Curdt [mailto:tcurdt@dff.st]
> Sent: Thursday, July 05, 2001 9:07
> To: cocoon-dev@xml.apache.org
> Subject: RE: [C2]: Proposal for intermediate output stream
>
>
> > 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.
>
> +0 from me if it's somehow configurable. Even more desirable for
> only parts of the site.
> --
> Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [C2]: Proposal for intermediate output stream
Posted by Torsten Curdt <tc...@dff.st>.
> 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.
+0 from me if it's somehow configurable. Even more desirable for
only parts of the site.
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [C2]: Proposal for intermediate output stream
Posted by Carsten Ziegeler <cz...@sundn.de>.
For finding the interesting part quicker, I double quote you:
> Giacomo Pati wrote:
> Yes, too late. IIRC you cannot set any headers when the
> OutputStream was been
> written to.
I think this could be true, so does this mean that the following
is not working?
>>
this.reader.setOutputStream(outputStream);
int length = this.reader.generate();
if (length != 0) {
environment.setContentLength(length);
}
<<
Carsten
> Giacomo Pati wrote:
>
> Quoting Carsten Ziegeler <cz...@sundn.de>:
>
> > > Giacomo Pati wrote:
> > >
> > > Quoting Carsten Ziegeler <cz...@sundn.de>:
> > >
> > > > > 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: 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
Re: AW: [C2]: Proposal for intermediate output stream
Posted by Giacomo Pati <gi...@apache.org>.
Quoting Carsten Ziegeler <cz...@sundn.de>:
> > Giacomo Pati wrote:
> >
> > Quoting Carsten Ziegeler <cz...@sundn.de>:
> >
> > > > 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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [C2]: Proposal for intermediate output stream
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Giacomo Pati wrote:
>
> Quoting Carsten Ziegeler <cz...@sundn.de>:
>
> > > 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: 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
Re: AW: [C2]: Proposal for intermediate output stream
Posted by Giacomo Pati <gi...@apache.org>.
Quoting Carsten Ziegeler <cz...@sundn.de>:
> > 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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [C2]: Proposal for intermediate output stream
Posted by Carsten Ziegeler <cz...@sundn.de>.
> 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
Re: [C2]: Proposal for intermediate output stream
Posted by giacomo <gi...@apache.org>.
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.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Proposal for intermediate output stream
Posted by Donald Ball <ba...@webslingerZ.com>.
On Thu, 5 Jul 2001, Carsten Ziegeler wrote:
> 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?
so long as it's configurable, +1. setContentLength is important for more
than just pdf's - if the http server is trying to use http keep-alives,
setting the content length is mandatory.
note you could look into using the output buffer provided by the jsdk-2.2
(or is it 2.3?)
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org