"Maybe we could ask clokep if he'd like to write something about js-irc? Why it is done, what the advantages are once it's done, how he is working on it (going through the specs), putting the jsProtocol code to test and adding missing pieces?" -- MicWait a second, what is IRC?
I guess this is a good first question, I'll steal from Wikipedia:
Internet Relay Chat (IRC) is a form of real-time [...] chat [...] It is mainly designed for group communication [...] but also allows [...for...] private message as well as chat and data transfers.Awesome, what's that really mean? It's an instant messaging protocol with an actual specification (i.e. it's not owned by some large, unnamed company), with open-source libraries for clients and servers. It's usually used by more computer-oriented types of people and centers around group conversation. Personally most of what I use it for is open-source software I use (I'm almost always in #instantbird, #maildev, and #songbird on Mozilla's IRC servers.)
Why it is done? What advantages are there once this is done?
[Edit: Florian suggested another question that wasn't originally covered, which some people more familiar with Mozilla code might be wondering.]
Why aren't you using the code from ChatZilla?
There's been a pretty steady decline in check-ins. I could take this code and attempt to whip it into shape and make huge sweeping changes and commit them back to ChatZilla, but honestly it was easier to start over for me. Regardless of ease, I'm not sure it would work any: especially since the ChatZilla code seems overly complicated and overly specific (since it wasn't really built as a library as far as I can see), especially since all the code is meant to deal only with IRC. The Instantbird code needs to be protocol agnostic to a degree, while is why it interfaces to purplexpcom.
- 2010: 0
- 2009: 5
- 2008: 15
- 2007: 11
- 2006: 18
A quick example of this is: ChatZilla uses a CIRCUser object, but for Instantbird I need to create either an imIContact or a purpleIAccountBuddy (depending on the situation). It's possible that's can be abstracted and code shared -- but I'm not sure it would be worth the effort. After all this, I should probably look more into the ChatZilla code, perhaps more of it could be used.
(If someone familiar with the ChatZilla code base -- I don't know who/if there's a maintainer -- is interested in talking with me, please get in contact here or on #instantbird. It's possible we could align some of what I've been working on, but I'm not sure how much could be shared besides the parsing algorithm).
What are the specific advantages for an end-user?
In terms of the IRC protocol itself, there shouldn't be any, my goal is for it to be a drop in replacement for the libpurple implementation with automatic account migration, etc. For end-users we can hopefully solve a few annoying IRC UI issues.
What about for developers? Anything cool there?
How is this being done?
Well I said up above IRC has a specification, right? Well, yes. There's the original specification, this was superseded by four different specification documents. Of which we only really care about one: the client protocol. So we have this updated specification (try reading it, it's rather painful), which is good. It's relatively straightforward set of commands and responses/errors. It's a bit more confusing than that though since there are a couple of extensions, etc. This is summarized below:
A lot of this is being done by reading the specifications and finding the proper responses, etc. I've also used Wireshark a bit to see how libpurple sends IRC commands (in particular, in what order it sends them in). A lot of my development is happening on live IRC servers, which isn't really best practice, but I'm mostly sending commands by hand to see the responses since a bunch of non-standard responses and extensions have developed beyond the above. I have been using beware irc to run a daemon on my own machine, however.
So how far along are you?
I've started implementing RFC 2812 and have a variety of commands done (the login sequence occurs automatically, the server connection is kept alive, messages can be sent to a channel and are parsed when received, a lot of the initial server information is displayed but unparsed). But there's a lot more to do! As my last post outlined, I recently was able to successfully get a chat to work in Instantbird from a silly bug I had been having.
Now that have the basics of chat working, I need to start handling the QUIT, PART and JOIN commands for when other users enter & leave chat rooms. Once these are complete it should be quite usable, although the entire preference system still doesn't exist, including notifying the UI of what options are available. In addition, I need to look into doing SSL sockets.
Once the protocol plug-in is done, we plan to abstract sections of it that will be useful for other protocols (in particular the socket connection aspects).
Where can I see this stuff...?
My work is kept in the "experiments" repository on Instantbird's Mercurial repository. There's also a variety of bugs open (they're listed above, I'm not going to re-list them), although not a ton is happening in them.
How can I help?!
Well you can of course feel free to download the code and hack on it, let me know (via IRC or any of the bugs most likely) if you have a patch you'd like me to apply. Or if you just found something that doesn't work you can feel free to let me know, although I probably just haven't gotten around to fixing it yet.
Also, if you've ever found something annoying / broken in the IRC implementation in Instantbird / libpurple please let us know (through any of the above contact sources).
Labels: Instantbird, IRC, Mozilla, programming