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]

(e-mail address removed) 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?

 

[petermichaux]

(e-mail address removed) said the following on 4/13/2006 11:29 PM:

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]

(e-mail address removed) 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]

(e-mail address removed) napisal(a):

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

 

[TheBagbournes]

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]

(e-mail address removed) wrote:

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]

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]

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

 

[VK]

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.

 

[petermichaux]

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

 

[petermichaux]

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

What is Blowfish?