with great fanfare we released 0.6 a week ago. at least i heard the fanfare. it sounded something like John Williams’ score to Star Wars. i know i’m not the only person running this on servers. i run it both on my test server (which thanks to a suggestion from Lance Haig) is getting even more spam daily and my home production server. the system is fairly stable, however there still seems to be a bug in the dreaded queue. no worries though as there is major work planned for 0.7 in the queue!
we had a great meeting friday where we discussed the things that we are planning for 0.7. unfortunately for everyone (especially me) i had a dentist appointment and had to duck out early. as a result of that (and not having others there) we didn’t get a chance to talk about the web bits which is another of the major tasks on the plate for 0.7. as for my part of it there is a lot of work. starting off i’ll be creating a new queue agent. this agent will work much differently from the previous agent. it’ll basically be a store agent that moves mail through a queue system inside the store. this makes some things pretty nice actually. for one we’ll finally be able to do a sensible version of “mailq” as all data is in the store. i’ll also be merging the logic for the rules agent into the queue agent. we need functionality inside the queue to know how to process mail based off document properties (think spam flagged or infected email) and figured we might as well move it all to the central location.
so the basic architecture will be as follows: each agent will have a collection that they manage -inbound and -outbound (names may change but the idea is thus). the queue agent will pick up mail dropped off in its -inbound queue and determine which agent needs it next. it’ll move the mail into that agent’s -inbound queue at which point it’ll get processed by the agent and dropped in its -outbound. mail will progress through the system until it is either delivered locally or remotely.
this will require some extensive changes to the system. obviously the new queue agent and the drop of the old one. it’ll also be a bit re-work of major portions of most queue agents. some really need it. store will also need some additions to make this all work, most notably a command which will allow the queue to move a mail from one store (the _system store) to another (the destination user’s store), and a way to do multiple a watch on multiple collections.
i’m SUPER — yeah, yeah i know, caps???? fat never uses caps — excited about this. i’ve long thought that the queue needed some major work as it is the last big portion of legacy code leftover from the 90s. i think it is an impressive architecture and i am still in awe of its original creator’s abilities, but it needs some big time love.
one other task came out of it for me and that was the continuance of valgrind. since we dropped memmgr we’ve found some pretty serious bugs that were causing us major issues. some were directly due to valgrind, and others were just due to crazy runtime issues.
all in all there is a load of work coming down the line. i don’t think i’ve been more excited for the changes though.