Standalone client work #41
Conversation
This became unused at some point but was never removed
This is the start of work attempting to remove the javascript sides dependance on twisted. The goal is to allow the client to directly contact the irc server over tcp or websockets.
Currently unused. it will attempt anything in BaseIRCClient.connections as a constructor for a connection class.
|
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:
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. |
|
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. |
This lets the client attempt to connect to the irc server directly, which performs better for everyone. will fall back to ajax when flash is unavaliable. UTF-8 decoding happens in javascript to avoid flash<->javascript stupidity and handle partial codepoints.
Currently this uses protocol name "irc" and expects one irc message per websocket message with no terminating CR-LF.
No description provided.