Hmm. Well after the last diary entry ...

I've actually been really busy on work recently. I've hardly left the house either, but thats not all work related (its the middle of winter here, and I HATE IT). I went to the shop for the first time in about a week today, I had basically run out of stocks of ready to eat food, and I didn't have the energy to make some more bread. I did make bread last week, the first loaf I didn't let rise enough, but the second loaf wasn't bad. Gotta find some fresh yeast from somewhere, maybe The Central Market. Anyway, I digress.

I spent a huge chunk of Saturday trying to work out how I could address one of the memory consumers in Evolution, that of the common string table. However, after spending a lot of time investigating in-memory b-tree's, extensible hash tables and the like, I figured I could only save 2-3-% of total memory use at the most, so it probably wasn't worth it. There's still the problem that the common string table never shrinks, but I have some ideas that can at least garbage collect no-longer used slots. But I dont think I'll bother for now.

I couldn't sleep in again this morning - last week was really fucked up. From Tuesday I think I slept from 4am-10am, then 4am-11am, then 10pm-4am, then 2am-11am. That was a long day. I seem to have digressed again, its probably the lack of sleep.

So yeah, I couldn't sleep in as much as I would normally, so I got up and started working on a list of what needs to be done to fix up Camel to make it suitable for it to become a separate library, and also just to address some design faults, and basics we should plan for for Evolution 1.6. Its a long list, but there are a lot of files to address, and most of the changes are pretty minor (namespacing, moving arguments around for api consitency, cAsE, etc). One fairly major issue I got pretty excited about was plugins, and plugin architecture.

Currently, Camel does have plugins - which is a lot more than can be said for Evolution as a whole at least. But only for mail store and transport types, very limited in scope, and they all have to be loaded fully at run time anyway. And none of the plugin code (albeit very little anyway) is reusable.

So I came up with a bunch of stuff (loosely based on the way the Eclipse IDE does things) that defines the plugin in some xml, lets you load in the plugin definition, perform queries on it about arbitrary (per-plugin-type) data, and then ask it to be loaded and invoke a factory method to create a new object or whatever from it. Interfaces are all versioned (rather simply, but it is there) too. Its a bit bigger than I would have liked, but its still only a few hundred lines of code. But ... the flexibility should be nice.

For a start I will be moving the various providers to sit under this new plugin api. Then the SASL methods will be a likely candidate (actually, they are trivial, so they might be first). Then comes the crypto mechanisms - although they still need some more api work. Then? I dont know, there are a bunch of other bigger and more important issues to fix. But some ideas might include pluggable indexers, or parser extensions, like detection of inline non-text data; binhex, uuencode, postscript, inline-pgp, and so forth, although they may well work better inside the mailer. Pluggable filter types would be nice too - although they could be a bit more work to integrate fully with the rest of the filter system; camel only knows about the lowest-level filter expression.

From there ... well, we'll probably just run out of time. But oh well. I would like us to use a similar system, in a fairly pervasive manner, throughout most of evolution proper. Ideally for everything from all of the menu's and toolbars, to context menu's, even to configuration screens, and the like (bugger it, even the system components themselves?). Somehow that might be a bit of a way off. Maybe to start with just a few baby-steps will be useful though, but BonoboUI will almost certainly make life hell for any of the interesting things. There's nothing to stop the system supporting bonobo-activated objects anyway, with some minor extensions. Actually for that matter, shell scripts, or alternate language plugins and the like could also be done - themselves as plugins extending the plugin system?

Thats my Evolution dream anyway - extensible, reusable, somethingelseable but its too late to think of it. And best yet, in ways and with code that I dont have to be responsible for!!! If it wasn't so cold it might even be enough of a dream to keep me warm at night (till my head burns out again, probably later this week), since nothing else is going to be any time soon.

I need to sleep more and ramble less.