Can an AJAX request be left open for multiple responses?

[petermichaux]

Hi,

Is it possible for an AJAX request to be left open for multiple
responses? This could avoid repetitive polling of the server.

Thanks,
Peter

[Randy Webb]

pe**********@gmail.com said the following on 4/13/2006 11:29 PM:

Hi,

Is it possible for an AJAX request to be left open for multiple
responses? This could avoid repetitive polling of the server.

Did you try it?

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[petermichaux]

Randy Webb wrote:

pe**********@gmail.com said the following on 4/13/2006 11:29 PM:

Hi,

Is it possible for an AJAX request to be left open for multiple
responses? This could avoid repetitive polling of the server.

Did you try it?

Is this code for yes? I haven't tried. I don't even know where I would
begin yet.

Peter

[Luke Matuszewski]

pe**********@gmail.com napisal(a):

Hi,

Is it possible for an AJAX request to be left open for multiple
responses? This could avoid repetitive polling of the server.
First of all, the HTTP protocol which is used by UA's or AJAX is
request/response* protocol (* response is not required) - so for one
request only one response can be done - the HTTP 1.1 enhancements (like
persistence and pipelining) happens behind the scenes... and from
within AJAX (XmlHttpObject) there is no way to enable/disable that
(only from browser setting - enabling HTTP 1.1 protocol.
From my point of view there is little point to ask here such generic

question... you will get better answers if problems you ask is more
concrete.

Best regards
Luke M.

[petermichaux]

Luke Matuszewski wrote:

pe**********@gmail.com napisal(a):

Hi,

Is it possible for an AJAX request to be left open for multiple
responses? This could avoid repetitive polling of the server.

First of all, the HTTP protocol which is used by UA's or AJAX is
request/response* protocol (* response is not required) - so for one
request only one response can be done - the HTTP 1.1 enhancements (like
persistence and pipelining) happens behind the scenes... and from
within AJAX (XmlHttpObject) there is no way to enable/disable that
(only from browser setting - enabling HTTP 1.1 protocol.

Hi Luke,

That sounds like a definitive "no". Thanks for the information. That
saves me a lot of time.

Peter

[Tony]

pe**********@gmail.com wrote:

Hi,

Is it possible for an AJAX request to be left open for multiple
responses? This could avoid repetitive polling of the server.

I've faced a similar situation, and AFAIK, you cannot open an
XMLHttpRequest and get back multiple responses. However, it seems that
you can keep the request open for an indefinite time.

Why not make the request, then the response handler can repeat the
request? So basically, you get the sequence:

-> UA sends Request 1
-> UA waits
-> UA gets Response 1
-> UA sends Request 2
etc...

Of course, you need to be aware that most browsers will only allow two
open requests at a time, so by doing this, you limit yourself to only
one usable connection.

[TheBagbournes]

pe**********@gmail.com wrote:

Luke Matuszewski wrote:

pe**********@gmail.com napisal(a):

Hi,

Is it possible for an AJAX request to be left open for multiple
responses? This could avoid repetitive polling of the server.

First of all, the HTTP protocol which is used by UA's or AJAX is
request/response* protocol (* response is not required) - so for one
request only one response can be done - the HTTP 1.1 enhancements (like
persistence and pipelining) happens behind the scenes... and from
within AJAX (XmlHttpObject) there is no way to enable/disable that
(only from browser setting - enabling HTTP 1.1 protocol.

Hi Luke,

That sounds like a definitive "no". Thanks for the information. That
saves me a lot of time.

People are rethinking this: http://alex.dojotoolkit.org/?p=545

But personally, I'd go for DWR's polling approach to "pushing" available
in version 2: http://getahead.ltd.uk/dwr/changelog/dwr20m1

ExG

[petermichaux]

TheBagbournes wrote:

pe**********@gmail.com wrote:

Is it possible for an AJAX request to be left open for multiple
responses? This could avoid repetitive polling of the server.

People are rethinking this: http://alex.dojotoolkit.org/?p=545

But personally, I'd go for DWR's polling approach to "pushing" available
in version 2: http://getahead.ltd.uk/dwr/changelog/dwr20m1

Thanks for these links. These ideas are very interesting. After reading
a few pages about Comet is sounds like it is still experimental. Maybe
the next generation of web servers will improve things.

I think for my situation it will be ok to just have the client poll the
server every couple of seconds to see if there are any changes. If the
client tries to make a server db change based on stale browser data, I
will produce some sort of error. Probably need this stale checking even
with a Comet-type system.

Thanks again,
Peter

[VK]

TheBagbournes wrote:

People are rethinking this: http://alex.dojotoolkit.org/?p=545

I may be terribly wrong of course, but the above looks like a
promotional scam. I base it on the wording, some details and the total
lack of real explanations and samples.

I believe it is the same pre-historic trick used to animate graphics on
the page before GIF89a format appeared: serve a hugely big content
length header so recipient stays in the receiving mode and keep
uploading packets. That was used for <img>, but maybe somehow it was
twisted for another object.

HTTP is an "ask it - got it - get away" protocol. One must be unsane to
install something on server to allow real long-lasting channels. It is
maybe semi-OK for intranet but on a real web server you will run out of
any resources sooner than you manage to say "oops".

Conventional socket listeners could be helpful and maybe added some day
- but sooner not, for security reasons.

To OP: no, it is not possible.

[TheBagbournes]

VK wrote:

TheBagbournes wrote:

People are rethinking this: http://alex.dojotoolkit.org/?p=545

I may be terribly wrong of course, but the above looks like a
promotional scam. I base it on the wording, some details and the total
lack of real explanations and samples.

I believe it is the same pre-historic trick used to animate graphics on
the page before GIF89a format appeared: serve a hugely big content
length header so recipient stays in the receiving mode and keep
uploading packets. That was used for <img>, but maybe somehow it was
twisted for another object.

HTTP is an "ask it - got it - get away" protocol. One must be unsane to
install something on server to allow real long-lasting channels. It is
maybe semi-OK for intranet but on a real web server you will run out of
any resources sooner than you manage to say "oops".

Conventional socket listeners could be helpful and maybe added some day
- but sooner not, for security reasons.

To OP: no, it is not possible.

Actually, I agree with you. "Comet" sounds flaky, and seems an attempt
to defeat the request/response nature of HTTP.

Take a look at DWR 2 though (and this is not a self-promotional scam -
I'm just a developer who uses it being a bit enthusiastic). The "Reverse
Ajax" capability will be great. The usage is asynchronous calls from
Java in the server. The implementation is a setTimeout() "thread" in the
browser which polls the server with XMLHttpRequests (I don't know if you
can set the frequency - you *should* be able to) and calls your
Javascript methods on receipt.

I've been planning features for our new intranet web app like user
alerts and reminders. Actions due, messages received, system actions
(like shutdown etc). And reverse Ajax is the way I'm planning to go.

I'll have a Javascript object in a page which subscribes to events, and
an event manager servlet started in the server to which you publish
events which broadcasts events to subscribed pages.

ExG

[Tony]

pe**********@gmail.com wrote:

Thanks for these links. These ideas are very interesting. After reading
a few pages about Comet is sounds like it is still experimental. Maybe
the next generation of web servers will improve things.

LOL -

First SOAP, then AJAX, now Comet - looks like I called that one right!

[VK]

TheBagbournes wrote:

Take a look at DWR 2 though (and this is not a self-promotional scam -
I'm just a developer who uses it being a bit enthusiastic). The "Reverse
Ajax" capability will be great. The usage is asynchronous calls from
Java in the server. The implementation is a setTimeout() "thread" in the
browser which polls the server with XMLHttpRequests (I don't know if you
can set the frequency - you *should* be able to) and calls your
Javascript methods on receipt.

I've been planning features for our new intranet web app like user
alerts and reminders. Actions due, messages received, system actions
(like shutdown etc). And reverse Ajax is the way I'm planning to go.

I'll have a Javascript object in a page which subscribes to events, and
an event manager servlet started in the server to which you publish
events which broadcasts events to subscribed pages.

IMHO it is still the same age old way first implemented in HTML Chats.
Simply get out all these "coolers" (from cool == awesome) from your
solution: Java servlets, AJAX, JavaScript OOP. The rest will be the
same plain vanilla HTML page al 1996/1997 with a form and a
meta-refresh set to say 1sec or 5sec.

The way the Internet works for this purposes is shown in AIM, ICQ or
any other instant messaging program. Client-side you have a socket
listener running on one of 65,536 ports. You also inform the server on
what IP are you on. As soon as new data available it informs you by
sending packets to the socket listener. This is the only way it works:
and it works great effectivewise and resourcewise. Anything else is
just a merry-go-round of ancient HTML tricks.

The question is how to get a socket listener for a browser and make it
communicate with JavaScript run on the page. The old time it was easy
with a small Java applet, but now client-side Java became a rare bird.

[BeeRich]

What I would do is create your request with your functionality, then
parse results. If you need some kind of delay, you could put this into
your logic, while keeping the back comm open, and you might be able to
parse on the fly.

Might as well try it. But separate your returned blocks through some
kind of parsing.

Cheers

[petermichaux]

TheBagbournes wrote:

Take a look at DWR 2 though (and this is not a self-promotional scam -
I'm just a developer who uses it being a bit enthusiastic). The "Reverse
Ajax" capability will be great. The usage is asynchronous calls from
Java in the server. The implementation is a setTimeout() "thread" in the
browser which polls the server with XMLHttpRequests (I don't know if you
can set the frequency - you *should* be able to) and calls your
Javascript methods on receipt.

I've been planning features for our new intranet web app like user
alerts and reminders. Actions due, messages received, system actions
(like shutdown etc). And reverse Ajax is the way I'm planning to go.

I'll have a Javascript object in a page which subscribes to events, and
an event manager servlet started in the server to which you publish
events which broadcasts events to subscribed pages.

Over the last few days I have prototyped a very similar system. The
client polls the server for new messages and then acts on those
messages appropriately. I'm curious what makes this "reverse AJAX"?

Are the DWR messages JavaScript that gets eval() when it reaches the
client?

My messages have been in the form of English. Any client side object
can subscribe to any English message. Any object can subscribe to any
string. For example an object might subscribe to "Pass the purple
turkey" message. This message does not have to be predefined. If the
server ever sends out a "Pass the purple turkey" message the
appropriate objects are notified and can do as they please. I may
switch to the server sending JavaScript messages that the client will
eval().

What I would really like to do is use this to update an unknown number
of parts of a page based on one or more messages. The goal is to avoid
stale browser views of the server database. The client event manager
will send out the server's message to find out which objects are
interested. The objects will respond to the event manager with a
request for a particular update. All of the requested updates will be
lumped together and sent to the server in one AJAX request. The server
will send a reply with all the necessary updates. If many elements need
updating this will limit the number of AJAX requests to only one. I
still have a lot of details to think through.

Peter

[BeeRich]

well all of these will be put into your parameters. What you COULD do
is Blowfish it or something so that it doesn't get messed around with
the back comm call. You could decrypt and parse into individual
'handler' assignments, then pack them all together into a global on the
server. Then, Blowfish it, bring it back, decrypt, split and do your
stuff via JS and park it into areas. Remember, this might all add up
on both client and server all for the sake of updating at the same
time. You could cascade your queries and make it efficient that way.

Good luck.

[BeeRich]

Actually, can you Blowfish in JS? I'm new to JS actually.

Cheers

[petermichaux]

BeeRich wrote:

Actually, can you Blowfish in JS? I'm new to JS actually.

What is Blowfish?

[BeeRich]

Encryption algorhythm. So a long string like:

?colour=red&flavour=blueberry&weight=8

....can be changed to:

1e634cb8c9c7fa7d6e13f4d2bdd37830a29739f6e24ae566c8 99a143b31cb5957567ba7f649e8719

Longer strings can be represented by shorter encryption though.