cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolás Lichtmaier <>
Subject Re: Content-length
Date Sun, 23 Jan 2000 21:51:40 GMT
> >  I think that sending data when the process hassn't finished is a
> > very good thing for certain pages: long pages, pages that come
> > with a slow backend.
> > I'd say that 90% time pages are small (less than 20k). And what do
> > you get by sending them to the client before (a couple of ms) the
> > page is done? So I'd said that buffering should be the default,
> > and it should be turned of by pages which need it.
> I agree enthusiastically: most pages are small in size thus requiring
> a relatively modest amount of storage. In the Cocoon environment,
> though, small doesn't necessarily imply "simple": more often than not
> otherwise "small" web pages will contain (possibly costly) dynamically
> generated content and will be subject to complex transformations.
> It's in this typical context that I feel there's a right place for DOM.
> I find DOM much better suited for some data-oriented, potentially
> complex transformations whose processing model results in final
> content being known only at the latest stage (thus enabling buffering).
> As an added bonus, yes, this includes the ability to properly set the
> content length whenever possible.
> This reminds me of a [heretical? :-)] post from Clark Evans in regard
> to the DOM/SAX dichotomy. Phrased as "DOM is right, SAX is wrong"
> I'd have expected it to trigger a flame war, but there was little follow
> up (mea culpa, too). I wish to hear more from Clark about this...

 I'm no expert on XML, but I've always have this idea... wouldn't it be
posible to have an abstraction of the issue? And that abstraction would be
some kind of partial DOM. The application would process the DOM tree. If it
touches something it hasn't arrived yet, it blocks until the data is ready.
Normal applications would be able to ignore this, thus forcing the whole
data to be ready from the very first DOM manipulations. But an application
expecting huge amount of data would be designed with some care, in order to
use the tree sequentially.
 The SAX API is too low level for my taste...

View raw message