Tags: refactoring

diesel, learning, evil, sweeti

Module::Pluggable gutting

I finally got round to completely gutting Module::Pluggable and refactoring it.

The upshot of this is that there's now Module::Pluggable::Object which has object orientated, as the name suggests, which makes it much easier to reafctor out into smaller methods which in turn makes it easier to subclass. The inner package stuff is refactored out into Devel::InnerPackage and then Module::Pluggable itself just has an import {} sub that instantiates a Module::Pluggable::Object and calls it.

This means that instead of shoving new functionality into the main class which was becoming increasingly large and brittle, people can sub class.

Less work for me. Yay!

diesel, learning, evil, sweeti

Collapse

And the third big ticket item for Data::ICal::DateTime was some refactoring of the recurrence-id stuff. I moved the stuff for unifying RECURRENCE-ID stuff into a seperate function collapse() which means that in EventQueue I can have a function which gathers all the events from all the providers and then collapses them where necessary. This is useful because that means I can add notes to other people's calendars for example.

    # $span is a DateTime::Span
    # $period is something like 'hour', 'day', 'month' etc etc
    my @events;
    foreach my $provider ($self->providers) {
        push @events, $provider->events($span);
    } 
    @events = Data::ICal::DateTime::collapse(@events);
    @events = map { $_->split_up($period) } @events if $period;
    return @events;
diesel, learning, evil, sweeti

Mariachi revisited. again

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