I don't know @baris I didn't notice it right away.
Juste today, 3 or 4 day ago after creation.
I suggest that I monitor this if that suits you of course
As you know, we use socket.io to power our real-time aspect. They've been on 0.9.16 for the better part of a year (perhaps more), while the team (a small one, like ours) has been working to refactor the underlying engine to a more stable, secure, and powerful one.
Off the bat, it generally means one thing -- that those users who can't access NodeBB for whatever reason due to their ISP (websockets blocked, etc) will no longer experience a "delay" before NodeBB starts working*. Some users (less than 1%) can't even use a NodeBB at all, because the mechanism that drops a websocket connection back down to XHR-based doesn't kick in.
Both of those problematic cases will be resolved when NodeBB is upgraded to use socket.IO v1.0.
* The way this works is: NodeBB loads, and attempts to establish a websocket connection. If after a delay, a connection isn't made, it falls back to xhr polling. Socket.io 1.0 will do this in reverse, xhr first (works in 100% of cases), and upgrade to websockets.
As you know, we use socket.io to power our real-time aspect.
I have a couple of questions:
We're looking to upgrade to socket.io 1.0 as soon as possible. We're blocked by an upstream module that allows us to listen to hook into all incoming events, instead of setting up listeners for each event. (for more information: lmjabreu/socket.io-wildcard#5)
Other alternatives may be better, we have not tested them as socket.io has performed admirably in all of our use cases.
We didn't do any benchmarks, unfortunately