0K Re: OpenMoko light web server

[Alexander E Genaud]

Well in practice, one shouldn't calculate the Fibonacci numbers to the
umpteenth power in Javascript. ;-)

Tim,

The HTTP request can be asynchronous in so far as the thread forks (or
rather continues until it dies). Typically, a simple Javascript
function reacts quickly to events such as page load, key presses,
mouse motion, etc. A synchronous HTTP request halts everything, while
an asynchronous request lets the thread continue. When the HTTP
request returns (and there is no active thread) the HTTP request
handler will immediately be called. I don't think this is
significantly different from other multitasking environments where the
context switches on device read/write. The difference, as I
understand, is that Javascript never preemptively says, "OK, you've
had enough fun, it's time for another thread to get a turn" -- heck
Windows is hardly preemptive and it seems to be acceptable to most
people.

I only meant to point out that in my experience, there does not seem
to be much difference between using async=true and handling
synchronous requests by separate objects with timeouts (that sleeps
the thread). The advantage of a Connection class is that you can have
a timeout that aborts the connection and attach delegates listening to
progress (4K blocks), etc.

I wonder if there would be an advantage in embedding the server in the
browser or vise versa. Then the whole issue of polling localhost would
be moot.

Alex

2007/4/17, Tim Newsom <cephdon at gmail.com>:
>
> On Tue, 17 Apr 2007 3:54, Alexander E Genaud wrote:
> > Tim,
> >
> > I believe Microsoft created the non-standard XMLHttpRequest object
> > through Active X around IE 5 but it has become something of a standard
> > implemented by Firefox, Safari/Konquerer, Opera, and perhaps others.
> > I've been using a nice wrapper, Sarissa, successfully for a few years
> > in many environments.
> >
> > http://dev.abiss.gr/sarissa/
> >
> > I believe the asynchronous flag is implemented in those major
> > browsers. Alternatively, you can create an HttpConnection "class" with
> > it's own timeout, abort, polling (4K), threading, etc. While the
> > details are different across browsers, it seems that threads never
> > context switches unless explicitly asked to do so (such as Timeouts
> > and alert dialogs). In other words, a "ring" might come in, but if you
> > are calculating the Fibonacci numbers to the umpteenth power, the
> > "ring" thread probably won't alert you in good time. I believe that is
> > true regardless of the async flag.
> >
> > Alex
>
> Alex,
>
> Hmm, that's interesting... It seems like a poor implementation if you
> can't guarantee that the event will fire asynchronously.  Why offer it
> at all?  Strange.
>
> --Tim
>
>


-- 
 亚 |      alex at genaud.net
 历 |      http://genaud.net
 山 | GPS:  [ 55.67N 12.588E ]
 大 | PGP: CCC7 D19D D107 F079 2F3D BF97 8443 DB5A 6DB8 9CE1