Override asynchronous (XMLHttpRequest) activity?

[Roadworrier]

Hey, does anyone know how I can pause the processing of
XMLHttpRequests so that I can have the foreground interface respond to
user clicks?

I have 40 graphs drawing to the screen after getting 1000 points each
from a cgi contact with a remote server. (40 XMLHttpRequest calls, and
40,000 data points on which some statistics are calculated.)

If the user clicks on a button, it can take as long as 10 seconds for
the javascript that fires when the button is pushed to activate...
even if it's just creating an Alert()!

I want the XMLHttpRequests to load as quickly as possible UNLESS the
user does something, in which case I want to pause everything so the
user can feel like they're interacting well -- a button changes it's
css class to highlight a key letter or unhighlight it. (Of course it
works fine as is with Firefox and Opera, it's just the browser
everyone uses, Internet Explorer, that responds so sluggishly.)

- Stefan

[Conrad Lender]

On 2008-09-30 21:29, Roadworrier wrote:

Hey, does anyone know how I can pause the processing of
XMLHttpRequests so that I can have the foreground interface respond to
user clicks?

I have no idea what you're doing in your scripts, but are you sure that
you're really sending *asynchronous* requests? Check if you have really
set the 'async' flag to true:

(XHR object).open(method, uri, async);

A locked-up user interface is usually the result of a synchronous
request - or, alternatively, bad application design:

I have 40 graphs drawing to the screen after getting 1000 points each
from a cgi contact with a remote server. (40 XMLHttpRequest calls, and
40,000 data points on which some statistics are calculated.)

Are you really sending *40* XHRs at the same time?
Why would you do such a thing?
And why would you be surprised by a lack of performance in this case?

As for your original question, no, you cannot "pause" XHRs. You can
cancel them (sort of), but if you design your application correctly, you
won't have to.
- Conrad

[Jorge]

On Sep 30, 9:29*pm, Roadworrier <[e-mail]:

(Of course it
works fine as is with Firefox and Opera, it's just the browser
everyone uses, Internet Explorer, that responds so sluggishly.)

There's no cure for IE...

--
Jorge.

[Roadworrier]

Thanks for the reply Conrad.

On Sep 30, 7:35*pm, Conrad Lender <[e-mail]:

On 2008-09-30 21:29, Roadworrier wrote:

Hey, does anyone know how I can pause the processing of
XMLHttpRequests so that I can have the foreground interface respond to
user clicks?

I have no idea what you're doing in your scripts, but are you sure that
you're really sending *asynchronous* requests? Check if you have really
set the 'async' flag to true:

* (XHR object).open(method, uri, async);

Yes, I set the async parameter to true, and I can tell it's true
because I can watch the results return asynchronously from the server
with Firebug.

A locked-up user interface is usually the result of a synchronous
request - or, alternatively, bad application design:

I have 40 graphs drawing to the screen after getting 1000 points each
from a cgi contact with a remote server. (40 XMLHttpRequest calls, and
40,000 data points on which some statistics are calculated.)

Are you really sending *40* XHRs at the same time?
Why would you do such a thing?
And why would you be surprised by a lack of performance in this case?

Well, not exactly at the same time. On station with one trace is
showed on launch, one XHR. The user clicks to add a 2nd station, and
then a request for that new station is added. If the user clicks on a
different trace type then two more requests are sent, for a the 1st
station trace type 2, 2nd station trace type 2. If the user keeps
cheerfully clicking away, they'll eventually end up with up to 40
requests. Probably by the time they select everything a bunch of the
requests will be processed since it updates "realtime", but at least
half will still be remaining.

It wouldn't be a bad idea to rewrite my C cgi on the server end to be
able to handle more than one request at a time so that when there are
20 unprocessed requests they can be sent as a batch. It'll make the
feel a little less "realtime" but overall performance might be
perceived to improve.

As for your original question, no, you cannot "pause" XHRs. You can
cancel them (sort of), but if you design your application correctly, you
won't have to.

I was able to improve user feedback performance on IE by making it
slower; I set a 250ms setTimeout before processing any new XML
requests, and that allowed the user click highlight to get processed
much quicker. Still not as quick as I'd like, but maybe quick enough
to keep the scientists using this thing happy.

Any thoughts on redesign are welcome, if there are no solutions in
Javascript like "write this html (via JS) to screen at a higher
priority"...

[Thomas 'PointedEars' Lahn]

Roadworrier wrote:

Thomas 'PointedEars' Lahn wrote:

>[...]
if (typeof window != "undefined"
&& /^(function|object|unknown)$/i.test(typeof window.setTimeout)
&& window.setTimeout)

I understand this example with the exception of the above line.

It is an attempt at determining whether there is a `window.setTimeout'
property that can be called, so as to avoid runtime errors since this DOM
feature is not universally available. First it is tested whether there is a
`window' identifier, to prevent ReferenceErrors when accessing its
properties; then the result of the typeof operation on its `setTimeout'
property is being matched against with a regular expression for results that
indicate methods

Doing such feature tests is usually recommended, especially for host-defined
properties; however, this feature has a rather long history, so you may not
need to test for it (it remains to be seen whether it can be considered safe
to use anyway).

Search this newsgroup and the Web for isMethod() and isMethodType(), which
are wrapper methods for this kind of feature test.

>HTH

It helps thanks.

You are welcome.
PointedEars

[Thomas 'PointedEars' Lahn]

[Full test expression restored]

Roadworrier wrote:

Thomas 'PointedEars' Lahn wrote:

>[...]
if (typeof window != "undefined"
&& /^(function|object|unknown)$/i.test(typeof window.setTimeout)
&& window.setTimeout)

I understand this example with the exception of the above line.

The statement is a feature test, an attempt at determining whether there is
a `window.setTimeout' property that can be called, so as to avoid runtime
errors since this DOM feature is not universally available.

First it is tested whether there is a usable `window' identifier, to prevent
ReferenceErrors when trying to access properties. If that test is
successful, the result of the `typeof' operation on its `setTimeout'
property is being matched against by a Regular Expression for operation
results that are known to indicate methods. If that test is successful, it
is tested whether the value of the property can be type-converted to boolean
true (since e.g. `typeof null === "object"' but `!!null === false'). The
last two tests are designed to prevent TypeErrors when the property is
called (as a method). Only if all tests have been passed, the following
block statement is executed.

Doing such feature tests is usually recommended, especially for host-defined
properties. However, this particular feature has a rather long history, so
you may not need to test for it (it remains to be seen whether it can be
considered safe to use anyway).

Search this newsgroup and the Web for isMethod() and isMethodType(), which
are wrapper methods for this kind of feature test.

>HTH

It helps thanks.

You are welcome.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16