So, I spent some more time working on BAFIRC. I ended up beginning the DCC layer, as it doesn’t seem to be too much of a jump over the CTCP layer. So far, I only have a similar infrastructure as CTCP has, receiving/sending and parsing the requests. I wrote some quick hacked up code for connecting to a DCC CHAT, however I still need to write more robust classes that will handle the connection layer and handle transferring files. This will mostly be a bunch of brain-numbing, boring code to write, so I may put it off, not sure yet. I am also debating on whether or not to implement an ident server. I’d like to run the core on a Linux box at some point, under Mono, but right now, Mono doesn’t have a stable release supporting .NET 4, so it will be Windows-only until that happens (unless you’re feeling adventurous, I hear that the current SVN head of Mono has full .NET 4 support). Obviously, on Linux, it an internal ident server won’t be used (for a couple of reasons I won’t get into here). I still think it will be beneficial to create, so I may whip one of those up - but again, that falls along the same lines as far as being mind-numbingly boring code to write.

Moving on to more interesting topics, I really need to plan out my plugin system. As I’ve said before, plugins will do just about everything, so it will be important to design this correctly. I’m going to use MEF composition (new to .NET 4) - so I just need to figure out the best way to expose the plugins. One way of doing it is to create an interface, or an abstract base class, with methods for all of the various events that may be called, and then just call them on all the plugins. Another option is to have metadata telling the plugin manager what to call and when/why to call it. However, neither of these approaches lines up with the whole Observable pattern I’ve been playing with and growing fond of. It seems like, in order to utilize that, I will simply require some sort of initialization function in each plugin that can then attach and subscribe to the various Observables it’s interest in (or ones that it derives from the base ones). My only concern with this approach is that it doesn’t seem too OOP-y. I think I can make it work though. One other thing I may support is some sort of permissions/security system for plugins - those of you who have installed extensions in Chrome or have installed applications on Android know what I’m talking about - the screen that shows you what permissions the extension/application requires before it’s installed/activated/whatever. You shouldn’t be loading potentially untrusted plugins into BAFIRC anyway, but I figure it will be a nice touch to show what sorts of messages the plugin hooks in to, and then restrict the plugin to using only those. I’m thinking of a manifest-like metadata attribute on the plugin, and then on plugin initialization, it sends this manifest to the plugin manager, which then can check that it’s been granted all permissions it’s asked for (or prompt/warn user if not), and then return an interface to only those event observables. This is still a fairly early and under-developed idea, but it’s a start (and it’s more than I had when I began writing this post)!

Anyhow, I’ve built another wall of text, so it’s probably time to sign off for now.