I do however very much want RCStream to be ahead of the curve and encouraging new software to be written in current versions of socket.io and not old ones. RCStream is currently implemented in Python and uses the gevent-socketio package. That package has not yet implemented support for the socket.io v1.0 protocol, so there's no upgrade available. It's been raised upstream (https://github.com/abourget/gevent-socketio/issues/192) however it seems the project is no longer seeing active maintenance.
Considering RCStream is a fairly small library, I'd recommend taking this opportunity to rewrite it in Node.js using the official socket.io server implementation (which is written in node) in favour of using a port.
|Declined||Xqt||T125197 Give hint to the current socketIO_client in ImportError of rcstream.py|
|Declined||None||T91393 RCStream is not accessible from python client due to using socket-io 1.0 while only socket-io 0.9 is offered|
|Declined||None||T68232 Upgrade RCStream backend to use socket.io 1.0 protocol|
|Resolved||Krinkle||T86803 Rewrite RCStream in Node.js|
I appreciate the enthusiasm but this isn't an opportunity for that. The RCStream software is pure middle-ware to publish the internal RCFeed to the outside world using the Socket.IO protocol. It doesn't have access to diffs. It will require added complexity in MediaWiki and RCFeed to make this work via RCStream. RCFeed is not meant to compute or distribute such large blobs.
Let's focus our efforts on RESTBase instead. Its low latency and deterministic scheme will cancel out most reasons for why fetching diffs is unattractive right now. Using RESTBase also requires less engineering effort to implement diffs and provides a more stable, maintainable and extendable platform.