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.
A little while ago, we decided that we would put some system configuration into the store, and rely more or less on access controls to govern who could read/write that data, which is quite a nice flexible system. However, although I knew the ACL system existed, I didn’t actually know anything about it, or even if it worked.
Like most things store related, the code is reasonably clear, and when you try it you find it basically works.
A couple of people now have asked how the store works. I’ve written a basic introduction to the features of the store, which is now available on the wiki – it’s called Store Overview, somewhat unsurprisingly, and should give people a reasonable idea of the basic structure.
We do have a store protocol guide too – linked within the overview – and although it’s both incomplete (the SEARCH command isn’t documented) and incorrect (stuff like HELP isn’t implemented, though that’s not a huge disaster!
First things, we just went past r800 yesterday – a commit I bagged myself, woo! Sadly no pretty graphs to show for it, but I think we’re back to a decent pace of commits again.
The work on the experimental branch of the Store is a good way through. This branch of Bongo builds reasonably cleanly, and works somewhat – you can deliver mail into it, and get mail out of it via IMAP.
I mentioned this on IRC, but I think it’s worth repeating again here: it’s looking like I’m going to be in the States for most of the week ahead. Pretty short notice, but oh well.
I do want to get another 0.2.9x release out soon, because some good bugs have been squished and the caldav stuff is now integrated, but we’ll see when. I’ll likely be online over there anyway.
Very excited to hear about the SMTP changes coming down the line. I’m still working pretty hard on getting the store a bit more responsive for IMAP, but the run-up to Christmas is pretty much always the busiest time of year for me.
When Pat said the following:
for lack of a better name, i named it bongosmtp_o for outbound. i’m sure there is a better name for the “agent that delivers smtp mail to remote systems”
We talked about it, and I did the form yesterday – we’ve applied as a mentoring organisation for this summer’s Google of Code. I’ve never done an application to GSoC before, although I’m familiar with many of the other projects who’ve taken part. In hindsight, I wanted to say a lot more on our application form, but ho-hum. It would have been nice to find something like OpenSolaris’ application before-hand, but I feel comfortable knowing that our application is completely our own 🙂
Recently, I decided I needed to move my server downstairs, but in order to do that I had to reduce the noise substantially – it’s going in our living room for now. It had the standard AMD fan kit on it, and a pretty awful power supply.
This is how it looks now:
I don’t think it’s going to overheat any time soon, and it’s really quite unnoticeable in terms of sound now – I can just hear the hard drive, and that’s it.
I had separate chats with people about MDB yesterday, originally about how we’re going to fix a potential security problem with Bongo, but went into a wider-ranging discussion about MDB. For those who don’t know, MDB is the LDAP-like API we use to store virtually all configuration.
There are a couple of issues with our code base right now:
The mdb.conf is world-readable, which is the security problem. This is necessitated by the current Dragonfly setup, which runs in the Apache process; Ideally, we want full configuration access from Hawkeye (the new web admin tool), also in a secure manner; Making MDB schema changes etc.
In general, using shared libraries already available on a system is a good thing. Witness the difference compiling against the system CLucene, rather than having to build your own:
real 3m0.256s user 1m39.937s sys 0m29.177s
$ time make # against the imported CLucene
real 6m27.311s user 4m30.465s sys 0m47.084s Basically, Lucene accounts for half of the entire build time. If you’re lucky enough to have a clucene development package on your platform (on Fedora it’s clucene-core-devel, on Debian it’s libclucene-dev), you can ignore the CLucene we package and use the system one.
