I’ve made a very important design decision in regards to BAFIRC and how processing of IRC actions (and, really, most anything else) will be handled. Perhaps some of you are familiar with *nix, and how, generally, everything is treated as a file. I’m adopting a similar approach - everything is a plugin.

Handling user registration and server ping/pongs? A plugin. Handling CTCP requests and replies? A plugin. Handling DCC? A plugin. Organizing messages into their respective user/channel buffers? You guessed it, a plugin.

I will implement a basic API that allows the plugins to interact with and control most anything in the core/client. Beyond that, a plugin will handle the rest. This allows me to keep everything very modular, and have no problems with figuring out where certain control logic fits in. The various layers in the code (such as the IRC layer) will be very minimal, and anything beyond the most basic of functionality will be implemented in a plugin.

I have, on paper, sketched out how some various pieces will look like, but nothing has been set in stone. I will implement my base plugin system using MEF (which, if I am not mistaken, was added to .NET as of 4.0). Plugins will be able to act on the core or on the client. There will be a basic API that will be the same whether the plugin is on the core or on the client, and there will be specific API extensions for core- and client- specific plugins. An example of a core-specific plugin would be the logging plugin, whereas an example of a client-specific plugin would be a /sysinfo or /winamp type of deal. It is also conceivable that a plugin could run on both the core and the client, and establish a communication channel between the two.

I have not yet decided how I am going to implement the core/client communications, but I do plan on supporting named channels between the two, so that plugins may talk with themselves, and other similar uses. I may just go with an XML channel, but I need to analyze whether or not this will fit my needs without being too wasteful. It’s an obvious solution for ease in developing clients for different platforms, but there is a bit of overhead, both in the XML itself, and the construction/parsing of it on either end.

DCC will be handled by the core and the client. I will likely support DCC proxying from the core, and for performance sake, support direct connection to the client in some cases. The core will be configurable with a default action, and clients will be able to override this action. I haven’t decided on how the client will be able to do this yet - whether there will be a notion of an ‘active client’ where the most recently used client can either handle or defer it to someone else, or if it will be more of a race, first client to respond gets it. In the case that all clients defer or none respond within a certain timeout (or if no clients are connected), the core performs its default action. Files can be sent from/received to either the core or the client (and transferred to/from core storage), though chats will likely always be proxied through the core.

I may have written down more things than I am remembering right now, but this is all that comes to mind. Perhaps I’ll be able to muster up the time to do some more coding tonight.

BAFIRC is too distracting to think about. During class, I was sketching out the architecture of my irc layer, plugins system, and core/client responsibilities. Yes, sketching on plain old analog paper.

I am posting this now from my phone. A more detailed posting with my thoughts will appear shortly, when I am on my laptop, rather than typing on my phone.

I began working on the IRC layer tonight. Part of that was implementing an IRC message parser.

I tested out the use regular expressions in writing it. I have a fairly complex expression that can capture the values from any RFC-compliant message. Works great!

I put this up against a non-regular expression implementation (from cbots) to benchmark. The non-regex version is roughly two times faster than my new regex version. I am currently debating if I should keep the regular expression parser (which has cleaner looking code, coupled with an ugly expression) or adopt an approach similar to what cbots does (which gives uglier code, but is faster). On my machine, the difference, in practice, is negligible. Regular expression parsing takes 77ms to parse 11000 messages, whereas the same set run through the cbots parser takes 33ms. Performance will be good enough in either case. So it comes down to which implementation I should use, and I’m not sure what I’m going to do.

On a side note, with school and work, it may be a few more nights before I can set aside enough time to make any more notable progress.

The first piece of BAFIRC is going to be the IRC communication layer. This layer will be totally standalone, making it easy to write first and test. There are several standalone pieces, but moving beyond that, everything will build on what has come before it.

I have thrown together IRC connection layers many times, using several languages. I could pull in one I’ve written before, but I’m starting from a totally clean slate and attempting to take advantage of the latest language features.

The IRC layer is fairly simple. The basic layer will support basic RFC IRC, including message parsing, message sending, message queuing (including a throttling layer to prevent you from flooding out the server and getting killed), all RFC defined commands and responses, and likely CTCP support. I am still undecided as to whether or not to include CTCP support in the base layer, as it is sort of an addon. DCC support will be separate, so I may make CTCP separate as well. I will provide hooks for these “addon” layers to plug in to, just to keep everything clean and modular.

I think I’m going to adopt an architecture similar to cbots as far as processing messages goes. I’m planning on having a single background thread that will manage both waiting to receive messages and sending messages (timer-based, to support message queuing). Once a complete IRC message is received incoming, it will be parsed down into an object and sent off to event handlers. Events will be fired for everything, giving a place for the core (or plugins, or any other non-BAFIRC uses) to plug in to and control anything.

That’s about all that comes to mind right now. The layer needs to be standalone enough that I can write a simple test program to get it on IRC. Once that is complete, I can begin working on other parts of the client, including the core server, web-chat support, logging system, etc.

Finally finished and turned in the paper I was putting off. That’s a weight off my chest now. It’s not my best work, but it will do (I hope…).

Economics exam tomorrow night that I need to study for at some point; I’ll probably study during the two hour break I have before that class.

Anyhow, time to kick back and watch some TV and write another blog post about something from BAFIRC. I need to design something so I can start coding on it shortly.