Mariachi revisited. again

Apr 20, 2005 13:10


Mariachi has scaling issues caused by the fact that it doesn't arbitarily break stuff up over month boundries because, well, threads don't stop just because it's the end of the month. That plus threading meant that it slowed to a crawl around the $n thousand messages mark, even when adding messages incrementally. This is sub-optimal.

A while back Ben Trott submitted patches to make Mariachi Atom aware which, AFAIK were never applied. That weekend I decided it would be better to let users write plugins without needing us to patch the main branch and ended up completely rewrting Mariachi to be Email::Store (for speed) and plugin (for extensibility) based which was nifty but, incredibly, even slower than before.

*sigh*

Then I got caught up in Buscador and the idea fizzled out but I think i might have another crack at refactoring Mariachi back to be plugin based and make some changes (one thread per thread page, oldest mails at chronological1.html and the latest as chronological${n}.html) to amke it faster and more intuitive (each message would be at ${message-id}.html). Then each plugin could take care of its own caching if needs be and how ever it wants - maybe using Netscape style summary files or DBM::Deep

netscape, intuitive, scaling, dbm, mariachi, sub optimal, plugins, html, break stuff, nifty, afaik, message id, caching, refactoring, style summary, email, threading, messages, chronological

Previous post Next post
Up