I have a big, complicated Javascript program that's doing some rather
complex things. One of the things it really has to do is to wait for the
browser to load something.

Because Javascript is all event-driven, the closest I seem to be able to
come is this:

loadMyFile("http://...insert url here...", function () {
alert("the file has loaded!");
});

That is, loadMyFile() executes asynchronously but registers a callback to
execute once the thing's loaded.

Unfortunately, while this works, it's a pig to program for. What I'd like is
for loadMyFile() to be synchronous: that is, it doesn't return until the
file has completely loaded.

(And I want to wait for other things apart from the file loading.)

It would appear that in order to do this I'm going to need multiple threads
of execution, somehow. I need to be able to have my main thread block, and
get woken up later by another thread. Is this at all possible?

Some experimentation would appear to suggest that all Javascript code on a
particular page, *including* code running in embedded iframes, appears to
execute in a single thread. Javascript on another page may or may not
execute in a different thread on my browser, but that's not terribly
important because I can't communicate across pages anyway.

Any suggestions?

I'm currently targeting IE6 and Firefox; I'd prefer standards-compliant
solutions, if any exist, but am willing to resort to hackery if I have
to...

--
+- David Given --McQ-+ "There is // One art // No more // No less // To
| dg@cowlark.com | do // All things // With art // Lessness." --- Piet
| (dg@tao-group.com) | Hein
+- www.cowlark.com --+

> I have a big, complicated Javascript program that's doing some rather[color=blue]
> complex things. One of the things it really has to do is to wait for the
> browser to load something.
>
> Because Javascript is all event-driven, the closest I seem to be able to
> come is this:
>
> loadMyFile("http://...insert url here...", function () {
> alert("the file has loaded!");
> });
>
> That is, loadMyFile() executes asynchronously but registers a callback to
> execute once the thing's loaded.
>
> Unfortunately, while this works, it's a pig to program for. What I'd like is
> for loadMyFile() to be synchronous: that is, it doesn't return until the
> file has completely loaded.
>
> (And I want to wait for other things apart from the file loading.)
>
> It would appear that in order to do this I'm going to need multiple threads
> of execution, somehow. I need to be able to have my main thread block, and
> get woken up later by another thread. Is this at all possible?
>
> Some experimentation would appear to suggest that all Javascript code on a
> particular page, *including* code running in embedded iframes, appears to
> execute in a single thread. Javascript on another page may or may not
> execute in a different thread on my browser, but that's not terribly
> important because I can't communicate across pages anyway.
>
> Any suggestions?[/color]

Threads are evil. They should not be used at the application level and
never at the scripting level. Learn how to use events. That is the right
way to do this.

http://www.crockford.com/javascript

David Given wrote:
[color=blue]
> I have a big, complicated Javascript program that's doing some rather
> complex things. One of the things it really has to do is to wait for the
> browser to load something.
>
> Because Javascript is all event-driven, the closest I seem to be able to
> come is this:
>
> loadMyFile("http://...insert url here...", function () {
> alert("the file has loaded!");
> });
>
> That is, loadMyFile() executes asynchronously but registers a callback to
> execute once the thing's loaded.
>
> Unfortunately, while this works, it's a pig to program for. What I'd like is
> for loadMyFile() to be synchronous: that is, it doesn't return until the
> file has completely loaded.[/color]

You haven't shown us what loadMyFile looks like but in browsers I know I
think script runs in the same thread as the GUI meaning if you have a
script being blocked by waiting for some resource to be loaded the
browser GUI is locked too.
Therefore synchronous loading is usually not a good idea.

If you are using XMLHttpRequest (Mozilla, Netscape, latest Safari and
Opera) or Microsoft.XMLHTTP (IE/Win) then you can however use the third
argument to the open method set to false to have a synchronous request.

--

Martin Honnen
http://JavaScript.FAQTs.com/

Martin Honnen wrote:
[...][color=blue]
> If you are using XMLHttpRequest (Mozilla, Netscape, latest Safari and
> Opera) or Microsoft.XMLHTTP (IE/Win) then you can however use the third
> argument to the open method set to false to have a synchronous request.[/color]

My current RPC system is a home-grown thing based around persistent
connections; it works scarily well, and doesn't appear to actually break
any standards (although they get bent quite a lot).

How portable is XMLHttpRequest? If I were to switch to using that, which
would be rather simpler, how badly am I going to restrict myself in browser
choice?

--
+- David Given --McQ-+
| dg@cowlark.com | "Anything that makes people that angry is worth
| (dg@tao-group.com) | doing again." --- Scott Adams
+- www.cowlark.com --+

David Given wrote:

[color=blue]
> My current RPC system is a home-grown thing based around persistent
> connections; it works scarily well, and doesn't appear to actually break
> any standards (although they get bent quite a lot).[/color]

Then what are you doing, loading stuff into a hidden iframe that calls
back into the parent window?
[color=blue]
> How portable is XMLHttpRequest? If I were to switch to using that, which
> would be rather simpler, how badly am I going to restrict myself in browser
> choice?[/color]

It is supported in Mozilla 1.0 and later (well at least 1.0 and later,
supported for that started in earlier Mozilla releases but I can't tell
the exact version) meaning Netscape 7.xy have it, Firefox releases and
other Mozilla based browsers.
IE on Windows has Microsoft.XMLHTTP since IE 5.
Recent Safari and Opera versions have XMLHttpRequest too, I think Safari
since 1.2, Opera so far only in the 7.6x preview and 8.00 beta releases.
Jim in
<http://jibbering.com/2002/4/httprequest.html>
also suggests that Konqueror has support for XMLHttpRequest but I have
not tested that so far and do not currently know which Konqueror
versions support that.
And Opera for instance appears at least currently not to focus on being
compatible to Mozilla's XMLHttpRequest (which was designed to be
compatible to Microsoft.XMLHTTP) but to have enough functionality that
GMAIL works with Opera. So even in the Opera 8.00 beta methods like
setRequestHeader or getAllResponseHeaders are missing.

--

Martin Honnen
http://JavaScript.FAQTs.com/

Martin Honnen wrote:
[...][color=blue]
> Then what are you doing, loading stuff into a hidden iframe that calls
> back into the parent window?[/color]

Yup. Been done, has it?

[...][color=blue]
> It is supported in...[/color]

It sounds like it either *is* supported on all browsers that have the
features I need, or *will be* supported, so I'll switch to using that ---
much more straightforward.

One thing I haven't been able to determine is whether it's possible to make
multiple requests on the same session, using HTTP pipelining. The
documentation seems to be a bit fuzzy. If so, it'd be really handy. Even
handier would be the ability to send data asynchronously from the server to
the client; again, the documentation's fuzzy, but it seems like that'd be
possible.

I'm actually a little surprised that this isn't being used more...

--
+- David Given --McQ-+
| dg@cowlark.com | Uglúk u bagronk sha pushdug Internet-glob búbhosh
| (dg@tao-group.com) | skai.
+- www.cowlark.com --+