[Javascript] Timing Issues

[Mike Dougherty]

Here's another idea:  If the user is only looking at a few key fields in
the browser, then only present those fields during the initial display.
When they confirm the result set is what they really want, THEN compose
the download for a bulk transfer.  (like writing a data file, then
redirecting the browser to an FTP download)

The "look and feel" stage would be improved in relation to the amount of
fields cut from the viewing process, and then the user is just going to
have to learn that half a million records takes a while to send over the
wire.  (maybe they'll learn to write better queries)

I'm not sure how PHP does buffering at the server, but in the ASP model
there is a .flush method that causes the buffer to be sent to the
browser each time it is executed.

-----Original Message-----
From: javascript-bounces at LaTech.edu
[mailto:javascript-bounces at LaTech.edu] On Behalf Of David Lovering
Sent: Monday, July 21, 2003 1:03 PM
To: [JavaScript List]
Subject: Re: [Javascript] Timing Issues


*This message was transferred with a trial version of CommuniGate(tm)
Pro*
I'm afraid even though the data selection is made from the client side,
the
data upload is server-side driven, and it only knows what is in the
query
that was submitted to it.  If a gazillion cells result from the query,
the
server is obliged to squirt them all upstream as fast as it is able.
[Customer specs are a real pain, aren't they?]

If we think the "flush" method might move the already constructed
<tr></tr>
blocks onto the screen, I'm perfectly willing to try doing a flush after
every record.  That would certainly improve the appearance of the
throughput, even though the total build time would be almost exactly the
same.

Just for kicks, does one do the refresh on the record, the table, or the
window?  (Or some baroque combination of all of them)...