ariscop
commented
10 years ago I actually wrote an extension to the twisted daemon that used websockets https://github.com/ariscop/iris/tree/websocket The response i got at the time was more or less "wait for upstream", since i was using the patch from bug 4173 as opposed to autobahn.
Is there reason to avoid direct connections? only thing the twisted daemon does with it's mitm position is provide info to adminengine, which i can't see being used over existing oper tools. The flash code is somewhat specific to my use case, it's replacing lightirc, but it places the least load on the irc networks, is the easiest to deploy and can rapidly fall back to other methods if flash is unavailable.
I really like the idea of a standalone Iris client, but I have a few comments:
Given the differences in goals and usage between a standalone Iris client and how Iris currently works, this should probably be developed as a branch, or in an entirely separate repo.
I'd rather this used one of the preexisting Flash-websocket shim libraries rather than including a simple Flash TCP socket implementation, because going with the TCP socket implementation requires four separate services to be running and user-connectable for a fully-featured deployment: 1) IRC server 2) websocket server 3) Flash policy daemon 4) Web server (to serve the Iris static content) Using a Flash-websocket shim means that direct connectivity to the IRC server can be removed (although the rest is still required).
As an aside, Iris's upstream project (Qwebirc) has recently added Websocket support as well, but has basically just used it to replace the long polling transport mechanism instead of using it to connect directly to the IRC server (that is, it still connects to a Twisted daemon server-side). I like this approach much better.