OpenMoko light web server
cephdon at gmail.com
Tue Apr 17 06:36:04 CEST 2007
On Mon, 16 Apr 2007 13:58, Matthew S. Hamrick wrote:
> Okay.. a few points:
> A. in a word, yes. But I think the main problem will not be the added
> response. In the old days when we bundled ORBs with browsers, we could
> receive asynchronous messages from the server. Why is this important?
> Because the phone (on the other side of the http interface) is going to
> ring or receive an sms message or the signal is going to go up or down.
> And these are things that occur outside the context of a client
> request. So, if you want to see if the phone just rang, you have to
> keep pinging the web server every second or so, and if it responds with
> icon on the interface. All in all this is pretty substandard.
Ok.. Well this is probably somewhat browser specific, but in the
XMLHttpRequest methods there is a synchronous or asynchronous flag.
Synchronously will behave in the normal request response method and wait
for a return before continuing to execute... Async will allow the code
to continue executing and then fire the response once it sees it. I
don't know if there are timeouts or not and I have not played around
with it much, but it seems like you could build several request
objects... One might be dedicated to the ringing function.. Then place a
timer on it and if there is no response by the timeout you could reset.
All the request would do is ask if the phone rang and wait.. Then your
cgi code could sit for the period of the timeout waiting for either a
request (to cover the situation of the phone ringing between requests)
or responding when the phone rings...
This should be more like the subscription model where you ask to be
notified and at any point it could happen. But, like I said, it may be
browser specific. /shrug
Just something to look into maybe.
More information about the community