April 20th, 2005

diesel, learning, evil, sweeti

URI::Title::iTMS fixages

URI::Title::iTMS is the plugin for URI::Title that copes with Apple's iTunes Music Store URLs. The problem was that it relied on a function from Net::iTMS that was only present in versions less that 0.1, namely

    my $info = fetch_iTMS_info( $uri )
     or die "iTMS / Not an iTMS url";
    $title   =
        eval { "iTMS / " . join(" / ", map { $_->{name} } @{ $info->Path } ) }
        || "iTMS / Error getting title from $uri: $@";

so upgrading to the latest version would break URI::Title::iTMS. After dicking around for a bit I realised you could get the same info out of the new one by using a slightly more convoluted route,

    my $r    =  Net::iTMS::Request->new( );
    my $info = $r->url($uri);
    my $path = $info->root->first_child('Path');
    $title   = eval { "iTMS / " . join(" / ", map { $_->att('displayName') } 
            $path->children('PathElement') ) }
        || "iTMS / Error getting title from $uri: $@";

So it was easy to do a

    eval { require Net::iTMS::Request };
    if ($@) {
        # first version
        # ...
    } else {
        # second version
        # ...
    }

I also noticed iTMS would do internal redirects with itms:// as the scheme which would, naturally, break LWP so I also added

    $r->{_ua} = MyLWP->new;
    $r->{_ua}->agent('iTunes/4.2 (Macintosh; U; PPC Mac OS X 10.2)');

with MyLWP being ...

    package MyLWP;
    use base qw(LWP::UserAgent);
    sub prepare_request {
        my ($self, $request) = @_;
        my $uri = $request->uri;
        $uri->scheme('http');
        $request->uri($uri);
        return $request;
    }

And it all seemed to work. HUZZAH!

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

diesel, learning, evil, sweeti

Jabber backend for Bot::BasicBot::Pluggable

On that note I really want to play aorund with shimming a Bot::BasicBot wrapper around either Net::Jabber or, more likely, POE::Component::Jabber. That way I could ahve all the power (*cough*) of an Infobot through an IM interface.

That way I could then pre-seed the factoids DB with knowledge - something like Wikipedia should do :) altough, in all seriousness, something like a mailing list would be interesting.

Yes, this is just a thinly veiled Desktop Dipsy all over again but I still think that a conversational interface might be a really interesting Intranet tool. After all, Ikea <spit hiss> do something very similar.

diesel, learning, evil, sweeti

Linux::Input::Info

For various reasons I have need of extracting various bits of information from the /dev/input/event* devices under Linux. Previously I'd been using this which was based on Gerd Knorr's input tools which felt a bit hacky.

John Beppu's Linux::Input doesn't seem to do quite what I wanted so I dug into Gerd's C and then wrapped some XS round it et voilá, it's all good. Enter Linux::Input::Info, stage left.

The only things I'm worried about are detcting whether or not there is a input device module on the system (I've got no non-input devices to check against) and memory leaks. I should really look at Devel::LeakTrace, Devel::ObjectTracker or Devel::Leak.