Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3AC10015.CE87EBC0@apache.org>
Date: Tue, 27 Mar 2001 16:03:17 -0500
From: Berin Loritsch <bloritsch@apache.org>
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: C2: trouble getting streaming to work as expected
References: <85CDFD92C550D311A1A40008C7DFA81A37B4DA@firewall.altacast.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Timm, Sean" wrote:
> 
> Berin Loritsch [mailto:bloritsch@apache.org] wrote:
> >Cocoon will use the BufferedOutputStream in just about every circumstance
> because
> >it is faster to the end user.  If you need deterministic timing on the
> serializer,
> >then you need a "DeterministicXMLSerializer" or something like that and
> perform
> >flush()es on each nugget of information.  Since Cocoon is designed for a
> transaction
> >oriented environment, the notion of what you are trying to due goes against
> how
> >Cocoon is designed to be used.
> >
> >This is the same with most Server Side Processing in a Web environment.  A
> transaction
> >occurs from request to response.  Once the response is fully sent, the
> transaction
> >is done.  There really isn't the notion of a progressive transaction.
> >
> >What is the end result that you envision by having a deterministic response
> on
> >the client browser?  I guarantee that once you start embedding that
> information
> >in tables, Netscape won't display the information until the table is closed
> (all
> >at once).
> 
> It may be true for Netscape, but is it true of all browsers?  What if it's
> not a table
> but, rather, just lines of text?  Even more so, what if the end target is
> not a browser
> at all but just another component making a request to Cocoon for an XML data
> stream to
> do with as it pleases?  A buffered stream may be a limitation in this case
> depending on
> what you're trying to do with it.
> 
> I'm not working directly with Fred, but I think I can answer in his stead.
> Basically,
> we have some data sources that take a very long time to retrieve data from,
> and we want
> the transformed data to start showing up on the browser as soon as possible
> rather than
> having to show some sort of progress bar indicating that we're actually
> doing something.
> If a particular browser doesn't immediately render certain sections of the
> HTML, that's
> okay, but, hopefully, it will render most of it.

Cocoon will send the information as it is transformed.  In my experience,
the BufferedOutputStream is a performance booster, and the differences on
the browser's end are so minimal it's not worth the overhead.  Asynchronous
IO is even more of a booster, but I am not willing to go that far in
complexity.

Again, Cocoon is designed for request/response transactions.  In the case
of another Component making a request to Cocoon, you will most likely be
using a SAX target.  In that case, you can be fully assured that the
information is sent as it is processed.  If you have to set up a special
case serializer where you are streaming the results to another server,
you can choose not to encapsulate the outputstream in a BufferedOutputStream.
In that case, you would have to create your own serializer anyway.

I don't really think that penalizing 99% of Cocoon's transactions based
on a couple of exceptions to the model is worth removing the Buffered IO.
What Buffered IO affords is the ability to send the stream in chunks
optimized for throughput.  It assumes that the destination is slower than
the origination.  Since Cocoon will be used mostly for writing to the
network or even disk, this is true most of the time.

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org