Nicola Ken Barozzi wrote: > > > Sylvain Wallez wrote: > >> Carsten Ziegeler wrote: >> >>> Might be worth investigating into running modes. Hmm. >>> >>> But comming back to the original problem ;) - We already have an >>> intermediate >>> output stream implemented and noone really complained about it: >>> Its the buffered output stream in the abstract text serializer...the >>> only >>> problem here is that a) the size of the buffer might be too small >>> and b) the stream is flushed on recycle(). >>> >>> So, if we >>> a) Move this buffered output stream handling out of the serializer >>> into the environment and >>> b) Don't flush the stream on recycling a serializer and >>> c) Add a small logic checking the buffer size for the current response, >>> >>> we have everything we need. >>> >> >> The output stream provided by the servlet engine is already buffered >> and we can control the buffer size using >> ServletResponse.setBufferSize(). Why do we need an additional buffer ? > > > Because Cocoon is not a servlet; it's mainly used as a servlet, but it > is *not* a servlet. > So regardless to what the servlet container gives us, we must ensure > Cocoon gets a neutral set of objects to work on.
I agree that Cocoon is not a servlet, but disagree with your conclusion : the environment implementation makes the bridge with the actual running environment. In the servlet environment, the Response is just a thin wrapper around the HttpServletResponse and the output stream is the HttpServletResponse's output stream which *is buffered* by the servlet engine, as stated by the servlet spec. So can't we extend the Environment contract by saying that the output stream should be buffered, and providing a new setBufferSize() method ? This will avoid useless and inefficient double-buffering in servlet environment (which is the one mostly used and where perfs and memory are critical), and, making the command line environment buffered should be a couple of lines in AbstractCommandLineEnvironment. We can thus have an environment-neutral Cocoon that relies on a buffered output stream provided by the environment, regardless what this environment is. >> What about exposing this method by adding it to our Request interface >> ? I already proposed this a while ago (see >> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101661438030015&w=2), > > > As I said, we need to expose a facade of the real stream, that is > indipendent from the environment implementation used. > > Thus we should wrap any stream that is given to Cocoon in a > CocoonStream facade, that we can control as you say, and in the > servlet case delegate to the servlet container. Maybe. This can give us more control on methods such as flush and close (which, BTW, are already trapped by servlet engines that implement persistent connections or chunked responses). >> including the proposal for setting the buffer size either as a >> servlet parameter or an attribute of <map:pipeline>. > > > Definately not in the servlet conf, as a pipeline hint maybe, as a > global parameter, surely. Don't know. It may be considered as a configuration of the environment, and thus given in web.xml for servlet and as a command line argument for CLI... Sylvain -- Sylvain Wallez Anyware Technologies Apache Cocoon http://www.anyware-tech.com mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
