[Zope] When does http reponse begin to be sent.

chas panda@skinnyhippo.com
Thu, 27 Jan 2000 01:23:56 +0800


>> On Sun, 23 Jan 2000 20:09:16 -0800
>> Sam Gendler <sgendler@impossible.com> wrote:
>> 
>> > It is an unfortunate aspect of human psychology that it feels much
>> > slower to wait for a long time and then receive quickly, than it
>> > does to just receive the document a little slower, but with less
>> > initial latency.
>> 
>> Actually, as IBM extensively researched and documented with their
>> old frame based terminals the reverse is generally true.
>> 
>>   Given a screen full of data which arrives, painting across the
>>   screen for a total of 10 seconds
>> 
>> or
>> 
>>   Given a screen which paints instantly after a 10 second wait
>>   during which nothing visually happens other than a possible busy
>>   bar
>> 
>> the majority of people will consider the second as far "faster" and
>> "more responsive".
>> 
>> There is however a riding caveat: Web users are trained to be able
>> to do something with partial data, to be able to act _before_ the
>> entire page has been rendered.  In the IBM world above, the base
>> assumption was that nothing could be done until the entire data set
>> (the "frame") had been received.
>
>This might be a `<table>' issue. If you generate one or more tables
>they won't be rendered until all their content is downloaded.
>In the HTML4.0 reference you will find hints to make it start rendering
>earlier.(it's just the matter of computing the number of columns and
>rows)

Yes, but I do believe that most seasoned web developers know to
avoid a table that encompasses the whole page. Most split the page 
into horizontal bands. Eg. the top table (which may encompass other
tables) is the banner. Then one or more for content. Then one for 
footer. Or some other permutation.

But returning to the desire to send HTTP headers and HTML back 
to the user before all the computation is done, I could relate
to that. In fact, one of the things that put me off Zope for 
a long long time was the inability to send back HTML before all 
computation for the entire page had been done. 
By comparison, with CGI scripting, I was accustomed to sending 
back the HTTP headers almost immediately, and even the HTML for 
the table encompassing the banner bar. Then and only then would 
things like sending mail, updating databases, etc  be done.
This had the advantage that the end user saw the top of the page
almost immediately. It appeared faster. Really.

However, when I started using these CGI scripts on large projects,
it soon became clear that there is a LOT more flexibility in doing
all the computation first... so that you can use a redirect, or set
cookies, or do other things with the HTTP headers that would otherwise
be too late if you'd already sent the first half of the web page. 

Bottomline : it appears a little slower the Zope way, but it's 
more flexible and has eased my development a great deal. 

chas

ps. Nice IBM anecdote, Sam.