incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nelson Silva <nelson.si...@gmail.com>
Subject Socket.IO vs Cometd
Date Fri, 01 Apr 2011 14:44:20 GMT
Hi all,

I've been trying to make it easier to integrate WAIB with other 
applications.
This would require removing the dependency with Jetty which isn't very 
easy due to the WebSockets support.

The guys in charge of Socket.IO java have a branch 
(https://github.com/Ovea/Socket.IO-Java) where they've removed explicity 
jetty dependencies and created an extension mechanism so I got in touch 
with Mathieu Carbou to see if they would be supporting other web servers 
and he told me that they've been discussing with the Cometd guys and 
would be holding the work on Socket.IO Java.

This is his reply to my question :

"For Socket.IO, we first planned to do a huge refactoring:
* migrate to latest socket.io JS version * adding features like event 
bus system (publish/subscribe like cometd) * adding queuing of offline 
messages * reconnections * adding native support for grizzly websocket 
(tomcat is already supported through continuations)

Most of these work is done in Ovea GitHub in js-eventbus project.

But since our project (jaxspot.com) must run over desktop, tv and mobile 
infrastructures, we faced an issue and found socket.io not as reliable 
as we would like. The connection is also very slow on non-websocket 
browsers and the library needs a flash application - we should be able 
to put it as optional.

By discussing with Cometd guys, they support websocket since their 
version 2 (which was released after we begin the work on 
Socket.IO-Java). Cometd guys supports less transports: the reason is 
that long polling is just plain ajax requests - so no need in current 
browsers to have iframe or script hacks. Also they do not support long 
streaming because only Gecko browsers is able to do this and they found 
some buffering issues with using streaming for a long time. Moreover, 
long streaming is useless because the protocol needs a ping/pong 
handshake each 15 seconds (done by Socket.IO). So there is actually far 
more connections made with long streaming that with long polling, which 
is the opposite of what we would have though at the beginning ;-)Their 
version 2 also support extensions, reconnection, and the client library 
works on all browsers. On server-side, they also use Jetty Continuation, 
bu we have the ability to add extensions (i.e. streaming protocol) or 
even probably other native support like grizzly websockets I suppose.

So we are currently holding the work on Socket.IO Java and we will soon 
do a PoC with Cometd. Since our web application is completely 
event-driven it would fit better. The big issue we have with Socket.IO 
is that we must develop things on top of it to make it more reliable / 
friendly, it needs a

I was wondering... What is the reason that made you also choose 
Socket.IO for Wave ? Is it the fact that there was only this library 
supporting WebSockets ? Or did you tried Cometd and found some 
limitations in it ?"

I asked for his permission to post his reply in this list and would like 
to know your opinion on this matter.

Best regards,

     Nelson Silva


Mime
View raw message