a long shot -> sending output to a browser question

[Cameron Laird]

In article <834rnasdnm.fsf at panacea.canonical.org>,
Kragen Sitaker  <kragen at pobox.com> wrote:
>bigredlinux at yahoo.com (Dan Allen) writes:
>> This may be far out, but something I have always wondered because I
>> thought I once saw a page do this and couldn't figure out how.  Is it
>> possible to trick the browser into thinking the whole page has been
>> sent and begin to display data on the page, and then send more.  If
>> you are wondering where I got this crazy idea, it was with the
>> NuSphere installation, which seemed to load the page over a period of
>> time.  The reason I ask here, is because they wrote it in perl (and I
>> didn't see any javascript on the page), and I figured it must have
>> been something they were doing with output buffering or something and
>> perhaps python had the same thing.
>
>Well, if you just want to display stuff at the bottom of the page,
>just continuing to send it will work fine.  (I wish Python had
>autoflush, but it's not hard to emulate with a proxy, and you can
>always just flush manually.  You'll need to flush, though, and make
>sure your web server and proxies aren't buffering either.  (At least
>Apache 1.3 won't; some servers will buffer CGI output unless it's from
>an nph-script.)  Then there's the browser; some browsers wait until
>they've received a few kilobytes before they start rendering, and
>others wait for a timeout or until they've received a few kilobytes.
>Most browsers wait until they've received a whole block-level element,
>such as a paragraph, before rendering anything, with the exception of
>tables, which IE 4+ and Netscape 6+ handle more or less cell by cell.)
>
>If you want to display it in the middle of the page, places you've
>already written stuff, you might need JavaScript.  (Hmm, maybe you
>could use CSS absolute positioning?)  One trick for this is to send a
>frameset rows="100%,*" that contains the page in a visible frame and a
>never-ending stream of JavaScript in another frame.
>
>"pushlets" was one approach to this, and there are some proprietary
>software products that do similar stuff.
>
>Hope this helps.  Let me know what you end up implementing.
>

"Multipart" is another answer.  Netscape browsers
(but no others, ever?) arguably conformed to standards
by interpreting "multipart" to mean (roughly) that the
HTTP connection should be kept open, with more data to
come.

I've written a couple of articles on the subject.  
While I'm in a dispute with their publisher about their
disposition, I'm happy to send correspondents drafts.
-- 

Cameron Laird <Cameron at Lairds.com>
Business:  http://www.Phaseit.net
Personal:  http://starbase.neosoft.com/~claird/home.html