15 lines
3.8 KiB
Plaintext
15 lines
3.8 KiB
Plaintext
Building a better IRC client
|
|
<p>I’ve been thinking about how to build a better IRC client recently.</p>
|
|
<p>The proximate cause is that I switched to irssi from chatzilla recently. In most ways it’s better, but it has some annoying UI quirks. Thinking they’d be easy to fix, I dug into the codebase and discovered that it’s a nasty hairball. We’ve seen projects where a great deal of enthusiasm and overengineering resulted in code that is full of locally-clever bits but excessively difficult to modify or maintain as a whole; irssi is one of those. Even its maintainers have mostly abandoned it; there hasn’t neen an actual release since 2010.</p>
|
|
<p>This is a shame, because despite its quirks it’s probably the best client going for serious IRC users. I say this because I’ve tried the other major contenders (chatzilla, BitchX, XChat, ircii) in the past. None of them really match irsii’s feature set, which makes it particularly unfortunate that the codebase resembles a rubble pile.</p>
|
|
<p>I’m nor capable of stumbling over a situation like this without thinking about how to fix it. And yesterday…I had an insight.</p>
|
|
<p><span id="more-4922"></span> </p>
|
|
<p>Probably the single most annoying thing about today’s IRC clients is that if you don’t leave them on all the time you miss some of the channel traffic. There’s no way to join a favorite channel and look at the traffic for the last half hour to get context that happened while you were gone, other than leaving your client actively watching it. And sometimes you don’t want a client distracting you with chat and urgent notifications.</p>
|
|
<p>So, I thought, OK, what if I built a client that logs all your IRC traffic for you? You’d still have the dropout problem, but at least it could always use the log to show you the last part of the conversation you were actually present for. Hm…but what about when you weren’t there?</p>
|
|
<p>That’s when I got it. I realized that because people think of IRC clients as ways to watch network traffic, they build them all wrong. Here’s how to do it right…</p>
|
|
<p>First, build a little client daemon whose job it is to watch channels for you and log their traffic, aggregating it into a message timeline that’s stored as a logfile on disk. The daemon gets started if it’s not already running, whenever you fire up your client. But exiting the client doesn’t kill the daemon. If you really don’t want to miss anything, you launch the daemon from your login profile well before you start your client.</p>
|
|
<p>Your client is just a browser for the message timeline. It doesn’t actually talk to IRC servers because it no longer has to. When it wants to send traffic, or join a channel, or leave a channel, it ships a request to the daemon, which is managing all the actual server connections. The response gets appended to the message timeline just like every other traffic and is then visible by the client.</p>
|
|
<p>Then I realized…I’ve already written this daemon! Almost all of it, anyway. It’s <a href="http://www.catb.org/esr/irker/">irker</a>, my replacement for the defunct CIA service. Add an option to log traffic. Add options to set your nick and its nickserv password. Done!</p>
|
|
<p>Those features are in the irker repo now. Not released yet because the code for nickserv authentication is untested, but that’s a detail. The point is that adding about 20 lines of trivial code has amped up irker so that it’s now a generic chat-logging back end that could be used by a whole family of IRC clients – every one of which could be functionally superior to what’s now out there.</p>
|
|
<p>To paraphrase XKCD: Code reuse. It works, bitches!</p>
|