cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolás Lichtmaier <n...@debian.org>
Subject Re: Content-length
Date Tue, 25 Jan 2000 03:03:33 GMT
> > > > It's not a problem with the DOM/SAX model, IMVHO. In both
> > > > cases the format in wich the data is supplied to the
> > > > serializer does not contain information on the content length.
> > >
> > > This can be viewed as a make-it-up-in-volume type of tradeoff
> > > similar to the first time hit on compiling JSP/XSP. You blow off
> > > trying to prepend the content-length for the first request for
> > > the cacheable page and then make sure that the cache contains the
> > > content-length for follow-on requests.
> > 
> >  The first time can be buffered, and the content-length printed as well.
> > Buffer has other benefits. With buffering, if a problem arises the user
> > might be shown another page, because nothing has been sent.
> 
> Yep... But just imagine buffering 30/40 megs of generated PDF and then
> sending them all to the client. It's too big to handle. And it takes too
> much time, because first you have to compose the thing and save it
> locally, AFTER, you can send it to the client...
> The cache mechanism could buffer to a certain amount of data (let's say
> 30/40 kb?) and if we can do it, we stream it with the content length,
> otherwise, we just avoid shipping content, stream all the content, while
> duplicating it on the disk, and on next request, we transmit everything
> (content length and data) from the cache !

 I fully agree. You wrote what I was thinking. =)

Mime
View raw message