setTimeOut and atomicity

[John Bokma]

Hi,

I am working on a simple chat program and want to use AJAX. In order to
get the new lines added to the chat I need to call a server-side script,
say every x seconds.

A second way to get those lines is to get them as a reply to the "add this
line" request when someone pressed the send button (or just enter).

So my idea was to:

get lines, and add them to the chat
setTimeOut for 5 seconds to get lines
if someone presses send, remove the setTimeOut, and
after receiving lines, setTimeOut for 5 seconds

The main question is: are the onClick handler and the setTimeOut atomic?
What I mean, should I see a browser as handling events atomic, and both
are events, hence it's not possible that the function registered with
setTimeOut is called in the "middle" of the onClick handler?

Thanks,

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html

[bobzimuta]

Re: setTimeOut and atomicity

A(synchronous) JAX is there to do just that. You can send a response
out and sit there, waiting for the response. When the response is
received, it triggers an event handler. You can have it call a
function. No need for timeouts. It is the server's responsibility to
send the response.

I made a simple framework based on the 'sack of ajax' framework, but
better ;). It will parse a response XML into an array so you don't have
to worry about traversing the structure. Let me know if you would like
it.

-Eric

--I had thought about doing something like this. I had previously done
a simple chat using Java (desktop and/or applets) for a project and was
fairly pleased, though javascript certainly has an advantage of not
needing the JVM.

[John Bokma]

Re: setTimeOut and atomicity

"bobzimuta" <ejmalone@gmail .com> wrote:
[color=blue]
> A(synchronous) JAX is there to do just that. You can send a response
> out and sit there, waiting for the response. When the response is
> received, it triggers an event handler. You can have it call a
> function. No need for timeouts.[/color]

Yes, there is a need, since I want to have new lines added even when the
user doesn't type at all. I know how AJAX works, and that it's async. The
question is more: what happens when the visitor presses send, and the
timeout is reached. Are such events handled one by one, or can the
SetTimeout handler interrupt the OnClick one (or vice versa)?
[color=blue]
> It is the server's responsibility to
> send the response.
>
> I made a simple framework based on the 'sack of ajax' framework, but
> better ;). It will parse a response XML into an array so you don't have
> to worry about traversing the structure. Let me know if you would like
> it.[/color]

I probably am going to have the serverside prepare the HTML, so the client
side only has to add the HTML. Probably the structure will be very simple,
e.g.

<response>
<chatlines> HTML (encoded) </chatlines>
<userlist>HTM L (encoded)</userlist>
<response>

regarding: AHAH is it not needed that the XML (XHTML) is valid? I seem to
recall that with AHAH one just uses the response "XML" directly, and not
the parsed result.

Moreover, what's the best way to encode the HTML? I was thinking of using
base64, but I recall that JavaScript has no encode/decode?


--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html

[Jasen Betts]

Re: setTimeOut and atomicity

On 2005-12-09, John Bokma <john@castleamb er.com> wrote:[color=blue]
> Hi,
>
> I am working on a simple chat program and want to use AJAX. In order to
> get the new lines added to the chat I need to call a server-side script,
> say every x seconds.[/color]

just call it and when it returns call it again have the server delay
its response if there is no new matterial, limit the delay to about 20
seconds (so stuff does't time out)
this way a correctly written server can give near immediate response to posted
lines instead of having to wait for the client to request, and also the idle
bandwidth is reduced.

this of course relies on you having access to a server that's capable of
this... this "getting" is the sort of thing that lends itself to a custom
written HTTP server that can track the posts and store a few minutes worth
in memory and queue up requests when there's no content to rend in response
.... - here there's no advantage to the separate application methodology
that's used for traditional CGI.
[color=blue]
> A second way to get those lines is to get them as a reply to the "add this
> line" request when someone pressed the send button (or just enter).[/color]

yes (but that's can get annoying) with the above running asynchronously
use a separate ajax call to post..
[color=blue]
> So my idea was to:
>
> get lines, and add them to the chat
> setTimeOut for 5 seconds to get lines
> if someone presses send, remove the setTimeOut, and
> after receiving lines, setTimeOut for 5 seconds
>
> The main question is: are the onClick handler and the setTimeOut atomic?[/color]

AFAIK while javascript is executing the all other events are suspended.
[color=blue]
> What I mean, should I see a browser as handling events atomic, and both
> are events, hence it's not possible that the function registered with
> setTimeOut is called in the "middle" of the onClick handler?[/color]

I thik JS is aingle-streaming, so no the timout handler won't iinterrupt
the click handler or vice versa. (but I think yoshoulduse readyStateChang e
on the request instread of a timout to trigger the downloads.

don't use setimeout on the client. and there's no need to use the posting
requests to retrieve content, keep them seperate - the code is easier.

sometimes a requests arrive out of order - possibly a good reason to no mix
downloading pathways

Bye.
Jasen

[John Bokma]

Re: setTimeOut and atomicity

Jasen Betts <jasen@free.net .nospam.nz> wrote:
[color=blue]
> On 2005-12-09, John Bokma <john@castleamb er.com> wrote:[color=green]
>> Hi,
>>
>> I am working on a simple chat program and want to use AJAX. In order
>> to get the new lines added to the chat I need to call a server-side
>> script, say every x seconds.[/color]
>
> just call it and when it returns call it again have the server delay
> its response if there is no new matterial, limit the delay to about 20
> seconds (so stuff does't time out)[/color]

20 seconds is a long, long time in a chat :-)
[color=blue]
> this way a correctly written server can give near immediate response
> to posted lines instead of having to wait for the client to request,
> and also the idle bandwidth is reduced.[/color]

Sounds like a good idea, will think about it.
[color=blue][color=green]
>> A second way to get those lines is to get them as a reply to the "add
>> this line" request when someone pressed the send button (or just
>> enter).[/color]
>
> yes (but that's can get annoying) with the above running
> asynchronously use a separate ajax call to post..[/color]

But then still the question remains: how atomic is this? I don't want to
end up with a part of one line, then a new line, followed by the rest.
[color=blue][color=green]
>> So my idea was to:
>>
>> get lines, and add them to the chat
>> setTimeOut for 5 seconds to get lines
>> if someone presses send, remove the setTimeOut, and
>> after receiving lines, setTimeOut for 5 seconds
>>
>> The main question is: are the onClick handler and the setTimeOut
>> atomic?[/color]
>
> AFAIK while javascript is executing the all other events are
> suspended.[/color]

So basically there is one even queue, and they are processed in order?
Or does suspend mean that execution of an event handler is interrupted
somewhere in the middle, and another gets started?
[color=blue][color=green]
>> What I mean, should I see a browser as handling events atomic, and
>> both are events, hence it's not possible that the function registered
>> with setTimeOut is called in the "middle" of the onClick handler?[/color]
>
> I thik JS is aingle-streaming, so no the timout handler won't
> iinterrupt the click handler or vice versa. (but I think yoshoulduse
> readyStateChang e on the request instread of a timout to trigger the
> downloads.[/color]

But I want to know for sure ;-)
[color=blue]
> don't use setimeout on the client. and there's no need to use the
> posting requests to retrieve content, keep them seperate - the code is
> easier.[/color]

Ok, I will have a go at your idea, which is interesting, thanks.

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html

[Thomas 'PointedEars' Lahn]

Re: setTimeOut and atomicity

John Bokma wrote:
[color=blue]
> The main question is: are the onClick handler and the setTimeOut atomic?
> What I mean, should I see a browser as handling events atomic, and both
> are events,[/color]

setTimeout() sets a timeout, that is not an event.
[color=blue]
> hence it's not possible that the function registered with
> setTimeOut is called in the "middle" of the onClick handler?[/color]

If you ask whether JS/ECMAScript is single-threaded, the answer is "yes".


PointedEars