Probably most people will have noticed a little bit of a lull in Bongo hacking. I seem to have spent most of the last month taking care of a close relative with broken bones, which has meant me spending a lot of time away from home. At least, that’s my excuse. We totally missed the M2 milestone, but hey-ho. I’m going to wait a couple of weeks before re-profiling, to see what rate progress gets made again.

However, I’m trying to hack again in earnest. Yesterday, I removed the dmc code from Bongo, which makes me immensely happy: it was horrible code, and it deserved to die. Basically we got rid of about 3000 lines of code, and all those 3000 lines did was produce a few numbers like “number of emails sent”. The feature:code ratio was ghastly.

Today, I posted a patch to -devel which makes bongo-manager read part of its configuration out of the store. The change is pretty simple, on the face of it. Previously, bongo-manager had a piece of code like this:

/* FIXME: these shouldn't be hard-coded */
static const BongoAgentSpec AgentSpecs[] = {
    { "bongodmc", MSGSRV_AGENT_DMC, 0, FALSE },
    { "bongostore", MSGSRV_AGENT_STORE, 2, FALSE },
    { "bongopop3", MSGSRV_AGENT_POP, 3, FALSE },
    { "bongocalcmd", MSGSRV_AGENT_CALCMD, 3, FALSE },

You can see from the comment that this is a problem. Why? Well, the only agents that bongo-manager knew about were the ones coded into it: if you wanted to add one, you had to recompile bongo-manager. Ouch.

This is now replaced with a document in the store, which looks a bit like:

{ agents: [ 
        { name: 'bongoqueue', pri: 3, enabled: true },
        { name: 'bongosmtp', pri: 3, enabled: true },
        { name: 'bongopop3', pri: 10, enabled: true },
        { name: 'bongocalcmd', pri: 7, enabled: true },

You can see that the structures described are very similar. However, how this is implemented is now totally different. If you want to add a new agent, you can simply go into the store and add it to the JSON document. If you want to disable or enable an agent, you go into the store and change the document. It’s very straightforward, and no recompilation is required.

I’m hoping that this is more or less how all agents will work: they will store their configuration in the store, rather than LDAP (as it is currently). This is much simpler a setup. It’s much easier to get in there and change the configuration, and you don’t have schemas and that kind of thing to worry about.

It’s possible, though possibly unlikely :), that sometime in the next week or so we can almost completely get rid of MDB within Bongo. It seemed like a big deal when we made the decision, but it’s looking increasingly easy as I realise how much infrastructure for all this we already have. Certainly, I predict that code using MDB in Bongo is going to start disappearing very soon.

What does this mean for end-users? Well, the first user-visible signs of this will be a couple of things. I’m hoping Bongo’s antispam and antivirus agents will be the first to make use of this new infrastructure, so we’ll be able to turn those back on very soon (we tried doing this with MDB a while ago, and it looked like a lot of work. I tried hacking on it. I didn’t get half as far as I have with this new stuff….). Also, we’ll be able to start working on Hawkeye, so that we have web-based administration again. And then we’ll really start rocking 🙂