So I want to create my own IRC client...

Question

I've wanted to make my own IRC client for a long time now. As soon as I switched from winfailure a few months ago (I think nearly a year now! ), actually.
As time went by I've slowly, begrudgingly gotten used to irssi, but with gritted teeth all the same. On winfailure, I used HydraIRC, and while this application was quite good, its supposedly open source license wasn't free as in free speech, only as in free beer. So while the code was open, it was only opened such that the code couldn't be used in other projects. Stab.
Anyway, I used this client for the better part of a year, and while it lacked quite a few things that would have probably turned others away like the complete lack of a scripting engine, it did what I wanted pretty well, and set an operational standard, if you will, that I got used to and have not found anywhere else. Yet.
So I want to recreate the standard I picked up on but for POSIX platforms (except for cygwin), and introduce some features of my own too. I simply don't know where to start, however.
Note that the subject says "create", not "write" - after asking around a bit in IRC ##linux recommended I try taking two IRC clients that have the features I want and merging their codebases. I've never done something like this before but I think it'd probably be fairly interesting, if not trying.
So, I'll list the features I'm looking for, and perhaps you can give me some suggestions on 1) how I'd either implement this myself or 2) a client with X feature already coded in. Thanks.
The features I'm looking for:
- Code Simplicity: This is the most important, to me, in the case of using others' code. Complex code (just look at rxvt if you want complex code) will just confuse and down-hearten me and make me run away.
- A network-oriented model: I want a client with a daemon, or server, that connects to my networks and performs most "heavyweight" takes, and a client, which just handles display. Quassel does this to an extent but is horribly underdeveloped and I don't have a system powerful enough to handle running Qt on a long-term basis (since I already tend to use GTK apps). I also don't know C++.
- Multiple clients: This is the second most important. I really need this one. I want to be able to have a "main" client that can connect to the server and manage general tasks, and a "light" text-based, console-driven client that connects and can be run over ssh, for example. Quassel completely falls apart here because it uses KDE's network-IPC libraries to transfer data from the server to the client, which a quick check with Wireshark showed to be binary. And I wouldn't want my "lite" client to require KDE, or at least KDE's libraries - that'd just be majorly weird.
- Speed: I want the client to be fast and responsive at all times, even on slower systems, and even when I'm connected to a lot of channels.
- Scriptability: It doesn't need to be complex, like Perl's library that applications can bind in. That's overmuch IMHO and, most importantly, slow.
I don't think one particular client meets those needs, but a few of you will probably shout "xchat!" Well, X-Chat is... not my thing. If irssi could be considered very far away from HydraIRC in terms of operation, X-Chat is the same distance away twice over. It doesn't operate the same way at all.
So, now that I've loosely explained the features I want, let me now explain another thing I want to be able to do.
Despite having hardware in dire need of upgrading right now (these systems aren't nearly that bad, but Firefox tends to eat my 512MB of RAM up pretty quickly, and I recently found all the PCs this house has in it 99% likely can't use DDR2 RAM, which isn't too good), I hope and believe that one day I'll upgrade to considerably better equipment with extensive graphics support. With this newer hardware I hope to create a new kind of UI model with animation integrated into the look-and-feel model of the UI the same way images are used for the same purpose today, GPLv3 license it so corporations can't steal it and use it in their products, and then bind it into my IRC client.
However, I want to start now, before I upgrade. With this in mind, I don't know whether I should make my own GUI toolkit, or use an existing toolkit now and rewrite half the codebase later to support my own graphics and animations. I'm not very good at making things that are programmatically extensible and flexible, so I don't really know what to do here. Simple hand-rolled toolkits such as dialogs with some text and a button can be managed in under ~250 lines of code, but anything bigger, and, well... you get stuff like GTK and KDE, whose toolkit libraries in total are both on the order of over a couple of MBs each, and have been in development for years, and continue to evolve rapidly today. If you're careful, you end up with FLTK, which I don't like the look of at all.
In addition to that, I want my client to be fast, even on slower computers. Right now, I have a 3-screen setup, with each screen being driven by a separate PC. The one on the right - the one I'd be putting my IRC client on - is a 450MHz P3 with 320MB of RAM. It runs X on a 4MB VGA card at 800x600. This is where I currently run an irssi session over ssh and screen. To give you an idea of the graphical power of this machine, antialiased Xft fonts with urxvt take 0.15 seconds to "scroll" when I say something in IRC. However, it's a capable PC if I harness its capability right, and is where I'd target my IRC client. And I dislike seeing my fonts redraw - I dislike seeing anything redraw, for that matter.
You might think I'm crazy, writing an IRC client for one of the slowest PCs in the house that works, that I in future want to extend to use a graphics layer that I hope to develop on a server-class Nehalem workstation with an insane amount of RAM and a pair of SLI'd GTX 280s in it.
I don't think I'm crazy. I'm using what I have to give back to the open source community, and using what I consider to be an cunning operational model to do it: back when the 450MHz P3 I spoke of was the only "main" working PC I had, I designed, in none other than Visual Basic 1.0, a media center UI. On Windows 98. In 2006. And, you know what, despite the fact that the animations it used were pretty basic, it actually looked really, really good. And why was this? Because I used software designed for 486DX2s running at 33MHz with 4 or 6MB of RAM, on a P3, with 128MB of RAM (yes, I've upgraded it since), clocked at 450MHz. The result? Blinding, optimized, speed. You really should try the older versions of VB sometime - I managed to score a copy of VB 2.0 which is legal to distribute because its "Make EXE" (ie compile) function is crippled. Email me and I'll mail you a copy - it's completely legal.
In the same manner, if I design this IRC client and carefully construct it so its client/server model works capably on my two PCs, my server (a machine not unlike the P3 I've been discussing - my server just has more hard disks in it, a 50MHz faster processor, runs my left-hand display and my IRC network) and my old desktop (the 450MHz box I've mentioned so much), when I finally bring it over to my new computer it'll be so fast that it'll be as if the computer is registering keypresses before I even type them. And that's the kind of performance I want to couple with shinyyy graphics.
Sorry this sounded halfway between a motivational speech, a request for help, and a coder's dilemma. lol
-dav7

Answer 1

Bit of an update: Varreon emailed me regarding VB 2.0 and we had a bit of a discussion regarding the language I planned to use.
He said it would be fine to post our conversation, so here's how it panned out:
Varreon wrote:...What language were you planning on writing your client in? I've written an irc bot in c++, and I'll upload my source code if you're interested in looking through it.
dav7 wrote:
Well, I'm not all that sure what language I want to use just yet.
I know I want it to be extensible, so I could either use a high-level, extensible but slow scripting language to power the client as a whole, or I could go down a path already travelled, proved extremely successful and in my opinion cleaner, and embed a scripting language, which would negate the requirement for a high-level language but still facilitate customization.
All the same, I'm not really all that sure what language to use.
C++ isn't really my thing - on my current computers, g++ takes maybe 3 seconds to compile the smallest of source files, and while that isn't *really * all that long, I'm not all that patient. As it stands I consider /gcc/ too slow for my preferences and use tcc instead - you might like to try it if you're on a 32-bit system.
I'll probably move to C++ when I get a new PC, but for now, all I really find fast enough for my liking is C, and I'm a little concerned that C might be a little too low-level for what I want to design here - beyond scriptability, I want the client itself to be easily extended in various directions. Of course the client will only appeal to a specific market (in an open source sense), but I do want it to feel organic and something that can be extended in as many directions as possible. So C probably won't be the language I use, and since C++ is slow to compile, it's probably going to be off the list as well.
All the same, I'm not concerned about speed in the irrational way I have been in the past, but at the same time I do need to be careful in my thinking regardless of the language I use since don't want a client that lags to death. A good example of a slow program is SciTE - the text editor I'm typing this in, Geany, uses the same edit control it uses (Scintilla, which is written in C++, AFAIK), and while this component has a good degree of editorial control, scrolling with the scroll wheel can be slow. Also, when I recently tried to run SciTE on an old laptop I found on the side of the road (AMD K-6, 350MHz, 32MB RAM), I discovered that just *typing* would lag the system horribly - typing about 15 keystrokes quickly resulted in a lag of about 6 seconds after which what I typed would appear all at once. Typing single keys - slowly - resulted in a delay of around 0.20-0.39ms (guessed).
Regarding scripting, I had my eyes on one embeddable language in particular but I forgot what it was called, so I headed to Wikipedia for a quick hunt-down session for it and managed to discover Falcon, which appears to use a VM but is at the same time the same insanely fast because it uses a C/C++-only policy for its modules. It also advertises itself as a scripting engine "ready to empower mission-critical multithreaded applications" so I'm considering Falcon to be a possible engine to integrate, and on a slightly long shot, even the language I might end up using. I also think hunting the first language I considered down and embedding that might be a nice idea, and I also might embed Perl. I'd love to be able to embed Ruby.
Overall however, I do need to contain my enthusiasm - the desire to throw in multiple scripting engines, awe-inspiring compositing graphics layers, and support for multiple protocols isn't such a bad idea, but if not controlled will result in serious featuritis, which when combined with a verbose, low-level language will only result in me throwing myself at the project too hard "to get it done", with proven disastrous results.
-dav7
[ Note, there's an update in a follow-up post below this one that affects the information you see here - just so you know ]
I've done some consideration since that email and it's possible that C++ might be able to be brought onto the table. This was mostly inspired by the good outcome I had with writing a couple of modules for InspIRCd, which uses C++, compared to my previous attempt when I knew no C.
The main thing I'm a little indecisive about at the moment is the toolkit; I want something that's fast but doesn't look all that bad; FLTK is, as I've said previously, not something I like the look of - it does appear to be somewhat themable but it's impossible to escape the fact that it values speed over shininess, and while this is excellent for my current target, I don't want to develop something that relies on it so heavily that it's next to impossible to port to whatever I end up using when it's time to get the graphics in, such as a UI model on top of an OpenGL canvas.
The second thing I'm unsure of is what scripting language I should use. I've done quite a bit of looking around - mostly to try and find that language I mentioned that I lost - and found quite a lot of possibilities, and even discovered that with some work (well, a lot of work, admittedly) it's even possible to embed Ruby into C++, and have Ruby call user-defined C++ functions and so on. It's not an official part of the project, but someone managed it nonetheless.
It seems to be possible to embed popular languages such as Perl, Python, Tcl, Lua, etc, but then there are lesser-known languages designed for embedding, such as Nesla, AngelScript and the like (such as that language I can't find, heh). And of course I could also embed a JavaScript engine, which would probably be very odd but all the same quite an experience.
Then there's Falcon, which appears to be a pretty good language in general but doesn't appear to have all that many modules available for it just yet, so doesn't seem to suit my purposes.
So, summing up:
- I don't know how I should develop this in terms of graphics - should I wait for a new PC and just use SDL or whatever I'm going to use, use a toolkit and either rewrite half of everything at some other point or juggle two display methods, or what?
- The number of scripting languages out there is mind-boggling. To me, it's not what syntax the language uses, or whether it's statically or dynamically typed, or how readable it is, it's #1 how fast it is, and #2 how suitable it would be in the context of an IRC client - string manipulation (even on every incoming and/or outgoing message), user interface control, and so on.
-dav7
Last edited by dav7 (2009-02-16 09:25:49)