HTML 5 Web Socket question

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
I have an AJAX application running on an embedded server (data
acquisition box).  AJAX is used to make the data display real
time-like.  I use the javascript timer for 2 second updates.

I would like to use a simple and ubiquitous streaming for changed
data, and ran across a discussion on comet and html 5 web socket.  The
web socket concept seems best, but the w3c site doesn't talk about it.

So my first question, is it real or in the future?  Where can I get
detailed how-to info on it?

Thanks for any help.


Re: HTML 5 Web Socket question

Quoted text here. Click to load it

HTML5 is only partially supported by a very few browsers.  If you have
Opera 9 or later, you can try
[ =] and
compare it using IE8 - it also does not work for Firefox.

That pages uses some of the new HTML5 form attributes -
[ /].

Adrienne Boswell at Home
Arbpen Web Site Design Services
Please respond to the group so others can share

Re: HTML 5 Web Socket question

Quoted text here. Click to load it

We've got some of this gubbenry working in the office (a hateful web
proxy that scans all downloads, and takes its own sweet time over
doing so). I was amused to see that it still uses Marimba to do so,
which I remember as a blecherous hack and abuse of HTTP from about 10
years ago.

I'd stick with AJAX and a client-side JavaScript ticker.  (BTW - Java
Restlets are a pretty nifty way of back-ending mid-weight AJAX)

I wouldn't touch _anything_ from HTML 5 with a bargepole, nor would I
expect support for any part of it to be usefully widespread in any
reasonable timescale.

If you want better advice, I'd start by asking why you don't like the
AJAX approach.

Re: HTML 5 Web Socket question

Andy Dingley wrote:
Quoted text here. Click to load it


The problem with AJAX is that to get to decent realtime I need a
faster update period (~0.2 sec.) and that creates network and device
problems.  The network problem is all of the traffic doing updates,
which so far is not too bad.  The larger problem is the embedded
device is both the web server and data acquisition system (cheaper
that way).  So ideally, the embedded system would only send updates
when needed, thus reducing its load.

I don't think either of these would be a worry if the web server was a
PC, but embedded devices like this have to work with realtime
schedules, and a lot of requests from the client can be a problem.


Site Timeline