Hi Andrew, On 23 September 2016 at 23:15, Andrew Otto <o...@wikimedia.org> wrote:
> We’ve been busy working on building a replacement for RCStream. This new > service would expose recentchanges as a stream as usual, but also other > types of event streams that we can make public. > First of all, why does it need to be a replacement, rather than something that builds on existing infrastructure? Re-using the existing infrastructure provides a much more convenient path for consumers to upgrade. > But we’re having a bit of an existential crisis! We had originally chosen > to implement this using an up to date socket.io server, as RCStream also > uses socket.io. We’re mostly finished with this, but now we are taking a > step back and wondering if socket.io/websockets are the best technology to > use to expose stream data these days. > For what it's worth, I'm on the fence about socket.io. My biggest argument for socket.io is the fact that rcstream already uses it, but my experience with implementing the pywikibot consumer for rcstream is that the Python libraries are lacking, especially when it comes to stuff like reconnecting. In addition, debugging issues requires knowledge of both socket.io and the underlying websockets layer, which are both very different from regular http. From the task description, I understand that the goal is to allow easy resumation by passing information on the the last received message. You could consider not implementing streaming /at all/, and just ask clients to poll an http endpoint, which is much easier to implement client-side than anything streaming (especially when it comes to handling disconnects). So: My preference would be extending the existing rcstream framework, but if that's not possible, my preference would be with not streaming at all. Merlijn _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
