Subj : Re: Threading in JavaScript
To   : comp.lang.javascript,netscape.public.mozilla.jseng
From : Gordan <gordan@bobich.net>
Date : Sun Feb 02 2003 01:40 pm

Douglas Crockford wrote:

>> Is it possible to use JavaScript to load an <iframe> and make a separate
>> function trigger once the iframe has been loaded? Something like
>>
>> <IFRAME src="http://someurl" onLoad="MyFunction">
>>
>> Will that work?
> 
> No. <iframe> doesn't do onload. I think you have some deep misconceptions
> about single-thread architecture. It makes things easier, not harder,
> unless you are trying to simulate multi-thread architecture in it. Work
> with the grain.

So, in order to defeat the waiting-for-download problem, each data file 
should be processed as it comes in. If I use the iframe to load each file 
separately, how can I make it execute the processing function as soon as it 
has finished loading? That way I don't need threading in JS, because I can 
download each file separately, and process each file as soon as it has 
downloaded - provides I can trigger a function when an iframe finishes 
loading...

>> I have already implemented a prototype of this in a server based (CGI)
>> application. I am now hoping to move as much of the work as possible to
>> the
>> client in order to save the resources. It can be very hard on both the
>> server and it's bandwidth proxying everything. If the data can travel
>> from the source directly to the client, it makes the whole system much
>> more distributed and scaleable.
> 
> You have some profound structural inefficiencies, it sounds like. Moving
> them to the client is not a solution. I contend there is a better way to
> think about the problem.

How exactly? If a number of files need to be downloaded and processed, then 
if that processing is done on the server, the server has to download them 
all (expensive on bandwidth), process them all (expensive on CPU), and send 
them to the client (more expense on bandwidth).

If the server only handles things like control and authentication messages, 
and the data travels straight to the client, it gets processed on the 
client. The overhead of sending processed data to the client is completely 
avoided, and due to latencies involved, it will probably all finish faster.

I agree with you that there is an EASIER way to think about the problem, but 
I have already implemented that easy solution. Now I'm trying to improve 
upon it.

Regards.

Gordan

.