I ran across some Java-based HTML5 websocket socket servers in my wanderings through Google, but at the moment I don't think any production servers support HTML5 websockets.

Of course, to make it work, you also need an HTML5 websocket client. I was interested to discover that the webkit browser has added support for that feature, although I don't know if it's in any production releases.

Customer surveys are for companies who didn't pay proper attention to begin with.

santosh joshi
Greenhorn

Joined: Aug 20, 2007
Posts: 21

posted Dec 22, 2010 06:47:23

0

Thanks Tim

I too Googled and find out that the following browser supports Web Sockets

Chrome 4.0
Firefox 4.0 beta
Opera 11 (or 10.70)
Safari 5.0.2

Also on Server Side Jetty 7.0 claims to have provided support for Web sockets and Servlet Spec3.0

Interestingly enough, this morning's reading popped up a warning from the W3C against rushing into HTML5. Apparently not only is support still spotty, but some implementation details haven't been totally nailed down yet:

Except that article pertains to Microsoft which only recently abandoned Silverlight as an interoperable replacement for the soon-to-be-defunct Flash (Silverlight is now being relegated to LOBs at best). The specifications are very, very stable although not finalized. Chrome, Firefox and Safari have long had websocket support; only IE requires an experimental plug-in. Unfortunately it still represents around 19% of browser market share. The good news is a) they are adding support, b) their market share continues to plunge.

Except that article pertains to Microsoft which only recently abandoned Silverlight as an interoperable replacement for the soon-to-be-defunct Flash (Silverlight is now being relegated to LOBs at best). The specifications are very, very stable although not finalized. Chrome, Firefox and Safari have long had websocket support; only IE requires an experimental plug-in. Unfortunately it still represents around 19% of browser market share. The good news is a) they are adding support, b) their market share continues to plunge.

I assume the dates on the posts are messed up right now. It says this message is from years ago, while the link is from last year and I just now received an email telling me there's a new response post.

Anyways - just wanted to add that I've been using the Google plug-in for MSIE. Not only does it properly drive websockets, but it got the whole darn webpage to work in MSIE. Since I ignored non-standard MSIE through development, and the page had never before properly displayed in MSIE, it seemed like a bit of a miracle. Here's a link to the instructions: http://highlevellogic.blogspot.com/2011/11/websocket-demonstration-on-microsoft.html

Just to bring things up to date: Firefox (and all Mozilla derivatives) and Google Chrome are ahead of the game, processing the final version websocket protocol that's becoming the actual standard. Opera provided the initial ideas for HTML5 and is still going strong on that. I wish they'd provide news on when they'll be running final websockets. I haven't heard any news at all on the possibility of websocket support in Tomcat, but it's part of the glassfish project (the part called grizzley). The only example application I found for it doesn't seem to work, so I guess it's out of date.

Roger F. Gay wrote:I assume the dates on the posts are messed up right now. It says this message is from years ago, while the link is from last year

No, the dates are fine. The article is dated Dec 21, and Tim's post was on the 22nd. What's weird about that?

and I just now received an email telling me there's a new response post.

Because there are new replies.

Anyways - just wanted to add that I've been using the Google plug-in for MSIE. Not only does it properly drive websockets

That may be great, but it's not generally useful. Web developers can't assume that end users will be using the plug-in and so have to still code for Microsoft's lack of foresight. The good news is that IE9 is miles more standards-compliant than previous versions. Too bad it took a market share in free fall to get Microsoft off its ass and realize that trying to set their own proprietary "standards" was a failing strategy.

Bear Bibeault wrote:The article is dated Dec 21, and Tim's post was on the 22nd. What's weird about that?

Oops. Haven't been around for a while and just looked on the left side --- at the dates people joined. lol

Bear Bibeault wrote:

Anyways - just wanted to add that I've been using the Google plug-in for MSIE. Not only does it properly drive websockets

That may be great, but it's not generally useful. Web developers can't assume that end users will be using the plug-in and so have to still code for Microsoft's lack of foresight. The good news is that IE9 is miles more standards-compliant than previous versions. Too bad it took a market share in free fall to get Microsoft off its ass and realize that trying to set their own proprietary "standards" was a failing strategy.

It's set up to automatically ask if the user wants to install Google Webkit. This allows developers to build and maintain one single version that is properly built according to standards. Let MSIE users go though that additional rather simple step of accepting installation of Webkit. I think anything else is foolish. MS doesn't pay me to write work-arounds for their coding errors, so why should I? Why should anyone be paying the bill for Microsoft development other than Microsoft?

Roger F. Gay wrote:It's set up to automatically ask if the user wants to install Google Webkit.

Which for me (if I used IE -- I don't even use Windows) and many other users would mean "Please visit another site".

This allows developers to build and maintain one single version that is properly built according to standards. Let MSIE users go though that additional rather simple step of accepting installation of Webkit

They're not going to do it. Most people won't even know what it is and will just go someplace else out of fear.

I think anything else is foolish.

I think your optimism is, well, overly optimistic. The percentage of people that will actually let it install is likely minute.

And thank you for calling me foolish.

MS doesn't pay me to write work-arounds for their coding errors, so why should I?

What coding errors? IE's non-compliance to standards is quite deliberate, not the result of any coding errors.

And support for IE's stubbornness is important because even though IE's share of the pie is dwindling, it's still a pretty big slice and you risk cutting them completely out of your audience. If that audience isn't important to you, go for it. Otherwise, you might just as well stamp the site as "IE users go away".

I'm a Tomcat fan too and it was one of the first questions I asked. It's my impression that you shouldn't hold your breath. Tomcat is still the servlet engine. I'm going to integrate my server with Tomcat along with HLL development tools and offer it free to developers. I'll also make it compatible with glassfish after they get it to work. I found one demo for it, but couldn't get it to work. Based on the comments below the article, I'd say no one else could either. The author said he'd check on it and then nada. But I have faith in it, so it'll work at some point - probably especially now that the protocol is stable.

Why? It looks like it's not been properly done; i.e. it doesn't say that it's full duplex ... just that the server can control client-to-client communication and it uses RPC. This may not be a real standard WebSocket package at all??

Why? It looks like it's not been properly done; i.e. it doesn't say that it's full duplex ... just that the server can control client-to-client communication and it uses RPC. This may not be a real standard WebSocket package at all??

Maybe I'm missing something here or not understanding what you mean?

Did you take a look at it? The demos, the entire code, the plugins and so on?

It has a Java based WebSocket server, pure JavaScript based WebSocket client with multiple subprotocols and additional clients for Java and Android plus the Flash based WebSocket Wrapper for cross-browser compatibility.

Why? It looks like it's not been properly done; i.e. it doesn't say that it's full duplex ... just that the server can control client-to-client communication and it uses RPC. This may not be a real standard WebSocket package at all??

Maybe I'm missing something here or not understanding what you mean?

Did you take a look at it? The demos, the entire code, the plugins and so on?

It has a Java based WebSocket server, pure JavaScript based WebSocket client with multiple subprotocols and additional clients for Java and Android plus the Flash based WebSocket Wrapper for cross-browser compatibility.

Again, maybe I'm missing something or misunderstood you, but I do not understand what is it that the jWebSocket project is missing?

I searched for the word "standard" and couldn't find it. The documentation ("infrastructure") shows that the part their calling a websocket is based on "JavaScript WebSocket", whatever that is. From there, looks like they might have built a chat system ... which is why I think their introductory page mentions server controlled client to client rather than full duplex (what websockets do). So, my take on it at this point is that they're doing a bit of marketing spin on a javascript based chat system. I don't know how well it works, but doesn't look like you should go there unless that's what you're looking for. It doesn't look like the best recommendation for a websocket system.

That's actually amazing, since the word standardized is right there on the home page... right next to "technology specified by W3C and IETF"

Roger F. Gay wrote:The documentation ("infrastructure") shows that the part their calling a websocket is based on "JavaScript WebSocket", whatever that is. From there, looks like they might have built a chat system ... which is why I think their introductory page mentions server controlled client to client rather than full duplex (what websockets do).

A part their calling a websocket??? We're definitely on the wrong page here... I have to ask what exactly are you talking about?

It's a Java based websocket server and it has a JavaScript based websocket client, plus several others.

Yes, there is a server and then there are clients which communicate via that server. If that's what you call "server controlled client to client" then yes, that's what it is.

It begins to sound to me like you're saying that websockets is a direct client to client communication?
Again, I do not presume to be right, but I do not think that's what websocket is.

Full-duplex means, as far as I know, the transmission of data in two directions simultaneously.

Roger F. Gay wrote:So, my take on it at this point is that they're doing a bit of marketing spin on a javascript based chat system.

marketing spin?
you have a take on it without examining it?

Its a JAVA based websocket SERVER with several websocket client solutions available as a bonus.