When I first started looking at ways to add support for non-websocket browsers to WiaB, I did look at Cometd. It was the first thing I looked at because I'd already done some work with it. However I eventually settled on Socket.IO because it's semantics where closest to websocket and I felt that implementing a Java bases Socket.IO server would take less time/effort than modifying WiaB to use Cometd.
That being said, I would fully support the use of Cometd instead of Socket.IO in WiaB. -Tad On Fri, Apr 1, 2011 at 7:44 AM, Nelson Silva <[email protected]> wrote: > 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 > >
