I’ll be heading out to Hamburg April 18-23rd with David and others for the Calendar project face-to-face meeting.  It will be great to meet Christian in person now that we’ve been talking on the phone discussing possible Calendar and Thunderbird changes.  I’m excited to make a quick overnight trip up to Copenhagen as I’ve never travelled there before.

Work

It’s great to see that Mark has started work with us. There’s lots to be done, especially on the address book, work that Joshua has developed in the Great Addressbook Rewrite.  I’ve started compiling some research of other addressbook / contacts systems so we can have some ideas of what current implementaitons do.

Other

As I got back home really late after Friday, well into Saturday morning, I didn’t end up doing much on Saturday.  So in my recovery time I poked around with my bugzilla link grabber extension and added a little AJAX to it.  And thus I feel buzzword compliant!

Note the lovely screenshot of the bugzilla info inlined at the bottom.  It might be nicer to create those elements as hovers to the bug links so they don’t take up space in the email but appear on mouse over of a bug link.

I just picked out a few things from the bug like bug number, status, number of comments, the title and the last comment text.  Other information might be a bit better, but it’s all available.

I did this by using the XMLHTTPRequest to the bugzilla bugs XML version (just add “&ctype=xml” to the url) and then running the result through XPath.  There’s a bit of a problem with the XML version as it gives you all the attachments as well as all the comments so things can be a bit slow when there are a lot of large attachments in a bug.

Anyway, not bad for a quick couple hour hungover hack.

Designer Code!!! eeek!!!

The code for all this is up on github in the ajax branch, check it out.

Who knew email didn’t have to be static!

Bugzilla links inside email messages.  I get countless messages where people reference bug 426175 but then don’t link to the bug.  The other option is for the person to include the link in the email which is ugly and pushes the flow around https://bugzilla.mozilla.org/show_bug.cgi?id=426175 because there is a large link inside the text.

Despite emails not being HTML mail, for whatever reasons, I still want bugs to be linked in a reasonable manner when I’m looking at my mail.  I couldn’t find an existing solution, though there likely is one hiding somewhere.  So I started a new extension to solve my problem.

The Bugzilla Link Grabber Thing

I’m not good with names, another reason I probably shouldn’t have kids.  (Offspring of Bryan Clark Jr.)

Here is a typical message that contains a mix of bugzilla urls and shorthand bug mentions.  You can see the urls are long and a bit ugly, while the short hand link mentions (even though this example mentions the same bug) are not linked to the bug itself.

Before you view any mail the extension takes the long bugzilla urls and converts them into the shorthand form.  It also linkifies any shorthand bugs into working urls.

Right now the extension only understands mozilla bugzilla and gnome bugzilla because that’s all I have accounts for.  But others could be added and I was hoping to have a preferences dialog that allows you to add alternate bugzillas (see TODO).  But otherwise it works great.

For xpi downloads, source, TODO, and more details take a look at the Bugzilla Link Grabber wiki page.

Fixing things

If you’re interested in this working for your copy of bugzilla or see some bugs in the code, don’t ask, please dive right in and fix things. Don’t forget to grab the STEEL extension or this one won’t work.  Also it only works on thunderbird nightly builds right now; but maybe that’s something you can fix.

I put the extension source up at github, sorry if that’s not your RCS of choice.  Anybody who creates patches to fix one of the TODO items is welcome to one of my remaining invites to github.  I don’t really have anything else to give…

Out of the Thunderbird status meeting this week I learned that there’s already a test extension available which gives Thunderbird Extension Developers some of the new STEEL interfaces.

What is STEEL?

STEEL stands for, Scriptable Thunderbird Easy Extension Library, and that means a simple javascript library to access your data (email, addressbook, etc.) inside Thunderbird.  Like it’s Firefox counterpart FUEL, STEEL will create an easy extension development API for Thunderbird.

What can you do with STEEL? 

Right now STEEL is in it’s infancy with a 0.1 release as you can see in the implementation plan.  However there already exists lots of things you can do with the existing STEEL code.

Here are some examples:

• Watch for New Mail
• Watch for Sent Mail
• List All Accounts

You’ll need to grab the latest STEEL extension from bug 408370, luckily there are STEEL Extension Install Instructions which you can follow.

Where is STEEL going?

What happens with STEEL is up to extension developers.  If you’ve already developed an extension for Thunderbird please give STEEL a try and let the developers know what you think.  If you’ve been thinking of developing an extension for Thunderbird try STEEL out to see if it does what you need.

The coming API will depend a lot on the kind of feedback that can be gathered right now. Join the conversation on the #maildev IRC channel or send a message to the mozilla.dev.apps.thunderbird newsgroup.

Personally I’d still like to see a couple things happen.

Simplify extension development by relying heavily on a local cache.  As a person who wants to try out a lot of different ideas inside Thunderbird via extensions I’d like to avoid network latency issues and would rather have all the information cached and indexed locally such that all calls could be fast and synchronous.  The only signal I would want to worry about is when the cache has updated so I can refresh my calls.

Allow for objects to be retrieved separately and by-directionally queried.  For example I’d like to be able to ask for a list of attachments and then for each attachment find out what message it was sent in, who sent it, and even other attachments they sent.

• for each ( attachment in Application.attachments )
  • from = attachment.message.from
    • for each ( attachment in from.attachments )

Improved Search APIs.  I got to talk with the excellent David Huynh of SEEK fame and asked if he could take a look at the STEEL APIs for improvements; I’m excited to see what he has to say.  Improving search is one of the major goals for Thunderbird 3 and all the great new ideas come out of extensions so development needs to be ready for that.

Malleable STEEL

A simple exercise I have been doing is to take an existing extension, even ones for outlook, and offer a Thunderbird extension developers perspective of the STEEL API .  Right now I have a breakdown of the Xobni Extension which I thought was very interesting extension that I’d like to see in Thunderbird in the future.  The breakdown examines different pieces of the extension with simple function calls that could enable it.