newbie: is this possible with ajax?

[Jeff]

Hey

Here is a scenario I'm wondering could be implemented using ajax:
user A are viewing the web site from his computer. Simultaneously user B are
viewing the same web site. user B decide to add some data (this could be
adding another row to a table). When user B is finished adding the new data,
the web site will refresh the gui at user A's computer...

I think maybe it could be done by implementing some kind of a timer in the
gui, it checks every minute to see if it need to update it's gui... is this
a bad idea from the performance point of view?. it uses more bandwith, but
people have faster connections today than 10 years ago...

if this is possible, then how?... a link to tutorial or example would be
great...

By the way, this is just a gui approach I'm considering. I have trouble
deciding on which gui layout the web site should have... this is some of the
criteria I have for the gui:
- the user should be able change font-size
- the xhtml/css should be 100% valid by w3.org validators
- the gui should be designed so that a new visitor should instantly knew
what to do at the site..

If you also have links to web site with great gui which are using google
map, then please send me the link.... I need some inspiration.

Jeff

 

[Pete Verdon]

When user B is finished adding the new data,
the web site will refresh the gui at user A's computer...

I think maybe it could be done by implementing some kind of a timer in the
gui, it checks every minute to see if it need to update it's gui... is this
a bad idea from the performance point of view?. it uses more bandwith, but
people have faster connections today than 10 years ago...

You're right not to be totally satisfied with the polling approach, as
it is rather wasteful and inelegant. Unfortunately, if you want to stick
with HTTP it is your only option. The HTTP protocol is fundamentally a
request - response one; there is no way for a server to reach out to a
client and tell it something.

The best you can do it try to make the polling as low-impact as
possible. A "nothing new" response should be as small as possible -
doing an HTTP HEAD and sending back code 304 if there's no change would
be quite nice, though I've never tried this and there might be cache
implications. Also, you might try doing some kind of exponential backoff
(google it) so that if a user leaves a page open and goes away you won't
have a connection every second (or whatever) for the next six hours.

Good luck,

Pete

 

[Laurent Bugnion [MVP]]

Hi,

Pete Verdon wrote:

The best you can do it try to make the polling as low-impact as
possible. A "nothing new" response should be as small as possible -
doing an HTTP HEAD and sending back code 304 if there's no change would
be quite nice, though I've never tried this and there might be cache
implications.

This works well. To avoid cache problems, simply add a time-based number
in a query string. The browser will consider that this is a brand new
URL (which it is) and will send the request. On the server, simply
ignore that query variable.

Also, you might try doing some kind of exponential backoff

(google it) so that if a user leaves a page open and goes away you won't
have a connection every second (or whatever) for the next six hours.

That'd be wise ;-)

I want to mention COMET as a possible alternative to the conventional
poll mechanisms. However, COMET has a lot of drawbacks, so I cannot
really recommend it. See this
http://www.irishdev.com/NewsArticle.aspx?id=2166

Good luck,

Pete

HTH,
Laurent

 

[Peter Michaux]

On Feb 3, 10:05 am, "Laurent Bugnion [MVP]" <[email protected]>
wrote:

[snip about server polling so that two users can work on the same page
and see changes the other user makes]

If you have GMail open on two computers this happens with polling.
I've played around with this kind of stuff. The tricky part is how you
will keep track of what changes need to be sent to the client with
each request in resource friendly way.

This works well. To avoid cache problems, simply add a time-based number
in a query string. The browser will consider that this is a brand new
URL (which it is) and will send the request. On the server, simply
ignore that query variable.

I think what you are saying is a practical solution. Apparently the
letter of the HTTP specs says that adding a query string to a URL does
not affect the browsers use of cache. I don't have a proper reference
to this. Just

"Handles caching correctly. (No querystring parameters - filename
timestamps)"

From <URL: http://synthesis.sbecker.net/pages/asset_packager>


I want to mention COMET as a possible alternative to the conventional
poll mechanisms. However, COMET has a lot of drawbacks, so I cannot
really recommend it. See thishttp://www.irishdev.com/NewsArticle.aspx?id=2166

Comet seems very problematic and ties up server ports for long periods
of time, doesn't it.

Polling can be used for high traffic web-based chat rooms so it may
not be as bad as first thought.

<URL: http://campfirenow.com/>

Peter

 

[Laurent Bugnion [MVP]]

Hi Peter,

On Feb 3, 10:05 am, "Laurent Bugnion [MVP]" <[email protected]>
wrote:

[About adding a time-based number to query string to avoid cache]

I think what you are saying is a practical solution. Apparently the
letter of the HTTP specs says that adding a query string to a URL does
not affect the browsers use of cache. I don't have a proper reference
to this. Just

"Handles caching correctly. (No querystring parameters - filename
timestamps)"

Yes. That technique works well, though. I didn't hear of any browser
having problems with it (ie fetching from the cache even if the query
string is different).

Note that with the corresponding server-side infrastructure, you can
easily avoid using query strings.

For example, you can very easily use a HttpHandler in .NET 2.0 to read
the current request's URL and execute another page instead. Google "URL
rewriting". This would allow using URLs in the form
"mypage-20070202194734012.aspx". Have the handler redirect to
"mypage.aspx" instead.

Comet seems very problematic and ties up server ports for long periods
of time, doesn't it.

Yes. Practically, you will probably need to upgrade your web server to
be able to handle COMET requests. That said, you will also
correspondingly reduce the number of messages sent forth and back, so
less traffic on the line.

COMET has another huge problem: The HTTP 1.1 specification recommends
limiting the number of connections from a given client to a given
server. The recommended number is 2 connections. In IE at least, this
limit is respected (though the IE team is not responsible for it, it's a
limitation in the HTTP stack used by IE). I am not sure about Firefox.
So if you keep a connection opened for COMET, you have only one left for
all the other traffic.

I thought good to mention it for completeness, but as I said, I can't
really recommend it. It's funny to play with, though.

Polling can be used for high traffic web-based chat rooms so it may
not be as bad as first thought.

It's not bad at all for non-time-critical applications. Chatting is not
critical, because it doesn't really matter if a message takes one, two
or five seconds to reach the client, as long as they all arrive in the
correct order.

<URL: http://campfirenow.com/>

Peter

BTW, I came acriss your blog the other day, when googling in order to
solve a problem I was having. It helped, so thanks ;-)

Greetings,
Laurent

 

[Peter Michaux]

On Feb 3, 10:54 am, "Laurent Bugnion [MVP]" <[email protected]>
wrote:

[snip about problems with COMET server-push]

COMET is definitely and interesting idea. There is another interesting
option I saw a while ago to enable server push. Apparently Flash,
about which I know very little, can open real, full-blown socket-based
connections with the server that stay open indefinitely. I read about
some software for doing this with Ruby on Rails called Armageddon
(which has since changed it's name) that used a Twisted server.
Anyway, somehow the JavaScript and Flash talk to each other and allow
server push. Sounds like a very cool idea but once Flash is part of
the whole system that changes the game quite a bit.

It's not bad at all for non-time-critical applications. Chatting is not
critical, because it doesn't really matter if a message takes one, two
or five seconds to reach the client, as long as they all arrive in the
correct order.

What web-based application should be that sensitive to timing? A
network stall could cause a delay of a few seconds on a regular basis
for any type server-client system over the internet. Maybe if the
server is in the same building as the client the LAN connection would
be considered reliable enough but even then the LAN could go down.

BTW, I came acriss your blog the other day, when googling in order to
solve a problem I was having. It helped, so thanks ;-)

Glad to hear it.


Peter

 

[Laurent Bugnion [MVP]]

Hi Peter,

On Feb 3, 10:54 am, "Laurent Bugnion [MVP]" <[email protected]>
wrote:

[snip about problems with COMET server-push]

COMET is definitely and interesting idea. There is another interesting
option I saw a while ago to enable server push. Apparently Flash,
about which I know very little, can open real, full-blown socket-based
connections with the server that stay open indefinitely. I read about
some software for doing this with Ruby on Rails called Armageddon
(which has since changed it's name) that used a Twisted server.
Anyway, somehow the JavaScript and Flash talk to each other and allow
server push. Sounds like a very cool idea but once Flash is part of
the whole system that changes the game quite a bit.

If that kind of functionality is needed, I would rather use a Java
applet. It's easy to have an invisible Java applet on the page, and
communication with JavaScript is very easy. Java applets can also open
sockets, so it's possible to use one for push-type applications.

Java has one huge disadvantage over Flash (in the browser): It's much
less widely accepted. People still think that applets are a big security
problem, and that Flash is safe.

What web-based application should be that sensitive to timing? A
network stall could cause a delay of a few seconds on a regular basis
for any type server-client system over the internet. Maybe if the
server is in the same building as the client the LAN connection would
be considered reliable enough but even then the LAN could go down.

You should come and talk to my marketing colleagues... We are working on
a building automation management station, of which one type will run in
the browser. One requirement was to have alarms being displayed maximum
500 milliseconds after the alarm was sent off by the sensor. Needless to
say, we are renegotiating that requirement, but still, there are huge
expectations. Unfortunately, rich internet applications make these
expectations even worse, because you show a righ GUI to the user, to he
kind of expects the same performances as the corresponding standalone
application.

That was "across", but you knew it ;-)

Glad to hear it.


Peter

Greetings,
Laurent

 

[Peter Michaux]

Hi Laurent,

Peter Michaux wrote:

If that kind of functionality is needed, I would rather use a Java
applet. It's easy to have an invisible Java applet on the page, and
communication with JavaScript is very easy. Java applets can also open
sockets, so it's possible to use one for push-type applications.

Java has one huge disadvantage over Flash (in the browser): It's much
less widely accepted. People still think that applets are a big security
problem, and that Flash is safe.

I've never done anything with Java applets and I think the huge
disadvantage is enough to sway most people the the flash solution. It
won't be long until there is real server push with HTTP anyway. I read
about it just a few days ago. Can't remember where but "they" are
starting to create specs for this.

With the Java applet approach would it be possible that the Java
applet is just a tiny little applet for the sole purpose of enabling
communication? I think that is how the flash solution works. That way
the JavaScript developer doesn't have to learn any Flash beyond using
some Flash library that makes all the communication magic happen.

You should come and talk to my marketing colleagues... We are working on
a building automation management station, of which one type will run in
the browser. One requirement was to have alarms being displayed maximum
500 milliseconds after the alarm was sent off by the sensor. Needless to

So it is assumed the security guard will react sometime within the
first half second? I'd say polling every 20 seconds would probably be
ok.

say, we are renegotiating that requirement, but still, there are huge
expectations. Unfortunately, rich internet applications make these
expectations even worse, because you show a righ GUI to the user, to he
kind of expects the same performances as the corresponding standalone
application.

That's an interesting way to word it. I'm going to store that for
later use when someone comes with unrealistic ideas.

Peter

 

[Laurent Bugnion [MVP]]

Hi,

Hi Laurent,

On Feb 4, 5:43 am, "Laurent Bugnion [MVP]" <[email protected]>
wrote:

I've never done anything with Java applets and I think the huge
disadvantage is enough to sway most people the the flash solution. It
won't be long until there is real server push with HTTP anyway. I read
about it just a few days ago. Can't remember where but "they" are
starting to create specs for this.

With the Java applet approach would it be possible that the Java
applet is just a tiny little applet for the sole purpose of enabling
communication? I think that is how the flash solution works. That way
the JavaScript developer doesn't have to learn any Flash beyond using
some Flash library that makes all the communication magic happen.

Yes, in fact I used to do this all the time.

First let me start by saying that I agree with your comments about
Flash, it's more widely accepted. From my past experience, I think that
the Java approach is much easier to implement, and also more powerful
(Java was made for networking, Flash wasn't). But for simple push
applications, probably Flash would be enough.

Anyway, I made the applet 1px x 1px, and even wrote a small Java class
which was getting the background color from the webpage (using
LiveConnect, so effectively calling JavaScript from the Java applet) and
setting the applet background color. This way, the UI was developed in
HTML, JavaScript was used to control the applet, and the applet itself
was doing the hard work in the background.

This is exactly how my (outdated) applet WebLoadFile works, a demo is
available here:
http://www.galasoft-lb.ch/_archive/myjava/WebLoadFile/Demo/Demo.html

So it is assumed the security guard will react sometime within the
first half second? I'd say polling every 20 seconds would probably be
ok.

My thoughts, exactly ;-) Unfortunately, we also sell to industries with
very strict (I didn't say unrealistic) (OK, I just did) security
standards... Try the swiss pharmaceutic industry...

That's an interesting way to word it. I'm going to store that for
later use when someone comes with unrealistic ideas.

Peter

Which words precisely?

Greetings,
Laurent