UPDATE (May 7th, 2012): Some of the information in this post is now out of date / inaccurate. See this post for more information.
This happens every couple of months – I go total heads down on a project, and I don’t blog. That’s no good for people who are interested in what I’m doing.
Filelink
So lately, I’ve been busy helping to get Filelink ready for its Thunderbird 13 debut. Filelink is a feature that allows users to upload attachments to Dropbox and YouSendIt (and more, soon), and then insert links into the emails instead of the whole attachments.
That’s a good thing. Every time you send a large attachment through e-mail, Tim Berners-Lee cries.
The Filelink work is almost done, which leads me to…
Address book
I went to some lengths last year to extend and improve the Thunderbird address book, and it’s still in pretty rough shape. For a while now, I’ve wanted to redesign it from the ground up – but some other project usually gets in the way before I can really tackle it.
With Filelink out of the way, I think I might get some time to hack on this.
But…I think I’m going to be taking a round-about route. Before I go into this, I’m going to need to mention The Kilimanjaro Event…
The Kilimanjaro Event
Damon Sicore is the VP of Engineering at Mozilla, and he recently posted about a new initiative at Mozilla, called The Kilimanjaro Event.
Salient point:
The Kilimanjaro Event is the point in time (not a release) when we realize a tightly integrated set of products that enables users to use the ID of their choice to find and install Web apps from HTML5 App marketplaces–including one created by Mozilla–and have those apps and appropriate data synchronized amongst devices. It is important to point out that the Kilimanjaro Event is not a single release. It is an incremental effort where we deliver a series of releases and features to each of our products that result in and enable an end-to-end user experience across these efforts.
One of the key components involved in reaching The Kilimanjaro Event is the mobile operating system that Mozilla is working on, code-named Boot2Gecko (or B2G).
Boot2Gecko (B2G)
Put simply, B2G runs web apps. Period. The B2G dialer? Web app. The settings manager? Web app. The lock screen? Web app.
The contacts manager?
You guessed it.
The Contacts App
B2G will ship with a series of apps (Gaia) – and among those will be an app for managing your contacts. I’ve gotten myself involved there, and have started getting my hands dirty in Gaia code.
So what’s the plan? How does this affect Thunderbird?
My idea is to work on this app for B2G, get it shipped, and then attempt to bring it over to Thunderbird, expanding it and specializing it where necessary.
This offers a number of advantages:
- The Contacts app for B2G will be entirely HTML5/JS/CSS based, meaning a lower barrier to entry for hacking on
- The Contacts app makes use of the Contacts API, which allows us to add an arbitrary number of email addresses, phone numbers, and all the other goodness that you’d normally expect from a modern address book
- Part of the Kilimanjaro Event is to have “apps and appropriate data synchronized amongst devices”. This includes contact data. This means that if we can get Firefox Sync brought over to Thunderbird, and rely on the Contacts API for contact storage, we can likely get contact synchronization pretty cheaply. That means that your Thunderbird contacts will be synchronized with your B2G phone (or whichever device is running the Contacts app). Not bad!
- Synchronizing with services like Facebook, Google Contacts, LinkedIn, etc – this is something that’s on the eventual roadmap for the Contacts app. Thunderbird can ride that wave too.
- Importing from services like those listed above are a pretty high priority, and will likely be supported sooner rather than later.
Now, a couple of things that worry me a little:
- I don’t want to fork the Contacts app, meaning that I want the core to remain the same as it exists in Gaia. Instead, I want to layer more code on top of the app in order to make it make sense in the context of a desktop application. Possible? Sure. Tricky? Almost certainly.
- The Contacts API isn’t currently supported for desktop right now – the WebAPI team is working hard on getting it working right for mobile first. Desktop is a distant goal.
- Also, the Contacts API is defined as an interface for accessing the device address book. For a phone, it’s obvious what that is. For a desktop, it means the OS address book. This means that, unless I’m misunderstanding, TB contacts will be going directly into the OSX address book, Windows Contacts, what-have-you. If no such service exists in the OS, Gecko puts together a fallback database for you.
Papercuts
Along with this contacts work, there are a bunch of long-standing Thunderbird papercuts that I want to smash through. Here’s a partial list of them.
I’m hoping to drop that list to close to zero for TB 15. Fingers crossed!
Anyhow, this appears to be my current trajectory, until further notice.
Thanks for the heads up, hope to have some good news about the address book soon 🙂
> This offers a number of advantages:
> 1. The Contacts app for B2G will be entirely HTML5/JS/CSS based, meaning a lower barrier to entry for hacking on
Honestly, I see this as a huge *DIS*advntage. No XUL means no overlays means no extensions means no customizability means not having the reason half of the users use Thunderbird to start with! I’d seriously reconsider this. I agree it makes a lot of sense to have it use the same API to get a lot of the benefits for free, but it seems to me that most of the “for free” parts are in the backend, not the UI.
Will Google Drive be included in Filelink?
Patrick makes a good point.
Pleased with this direction. Awesome!
Among the advantages I would more explicitly state that this would allow for Thunderbird to Thunderbird sync. This is rather appealing to me.
>This means that if we can get Firefox Sync brought over to Thunderbird, and rely on the Contacts API for contact storage, we can likely get contact synchronization pretty cheaply.
Well.. there’s already carddav which does this, and it works. Please don’t reinvent the wheel here and bring native carddav to Thunderbird!
Hey Patrick,
> Honestly, I see this as a huge *DIS*advntage. No XUL means no overlays means no extensions means
> no customizability means not having the reason half of the users use Thunderbird to start with!
Thankfully, XUL is not a requirement for extensions anymore. Jetpack and the Addon Builder (https://builder.addons.mozilla.org/) are proof of this. So I must respectfully disagree with your assertion.
Customization and add-ons are a huge part of Thunderbird (and Mozilla), and I don’t see that changing.
So it’s a pretty safe bet that the Contacts app will be extendable.
Thanks for commenting,
-Mike
But you’re only disagreeing with the second half (extensions): do the Jetpack/Addon builder actually let you overlay content? It’s my understanding they don’t, AFAIK they let you add a bunch of HTML widgets here and there, but not dramatically change the UI of something (like changing a binding so it changes the look everywhere it appears or overriding the behavior of a particular method of a binding…). I’m sure some of this can be done in HTML, but it would not be as clean.
Besides, why would I learn an extra (complicated) API for Jetpack when I can just use the real API? (I should note that I don’t really get why Jetpack exists, I think restartless extensions were great, but you don’t need Jetpack to do that…) I have to respectively disagree with the assertion that “HTML5/JS/CSS [is] a lower barrier to entry for hacking on.” Basic XUL/JS/CSS is the same barrier of entry as HTML (probably less in fact since Mozilla has pretty good documentation on it, unlike HTML which has lots of bad documentation mixed with the good).
Besides, XUL has a whole lot of platform look & feel widgets already, why would you not want to take advantage of that? One of the reasons I’ve often heard cited about why people prefer Firefox, Thunderbird (and Instantbird :P) is that it looks native on every platform: it’s not a GTK/Cocoa app on Windows. Wouldn’t you lose this if you switch to an HTML layout. Of course you can make an HTML layout look pretty, but you’d spend a ton of time customizing it to make it look NATIVE, when all the work is already done for you with XUL.
I still assert that it makes sense to share the backend with a mobile UI + a desktop UI on top of it. You could easily create XPCOM components to interface with different services (Facebook, the OS address book, what-have-you) with no specific UI information. So really what I’m saying is, I agree that sharing code is awesome! Sharing the UI? Not so awesome: is UI designed for a phone really good for use in a desktop application?
That’s good to hear! It really is one of the greatest strengths of the Mozilla platform.
Thanks for responding. I’m excited to see the address book redone! (Hopefully you don’t think I’m trolling, I just disagree with this trend toward HTML; it really defeats one of Mozilla’s biggest strengths.)
Great news, great direction, I hope SeaMonkey’s Address Book can pick it up.
I have up to 5 entries in my current address book for a single entity just because of the 2 email address limit. Since I am using an add-on to sync to Google, this means my Google address book is kind of fragmented. I so look forward to a more robust address book, especially if it automatically syncs from Google!
I always appreciate it, when good projects come along and get new features, but how cares about filelink, thats a nice gimmick and maybe nice to have.
I think really much people wait for an addressbook with native carddav support, which is capable to compete and really share contacts with that apple i[whatever] stuff without the need of a extension (which most of the time only worked with the projects own server in the past).
Further would it be usefull to have an account management like macs have, where you create a dav server account and then simply ckecks which addressbooks or calendars you want to have.
Since there are many server projects out now, who support card- and caldav, everyone awaits an open source client, available on every platform, with really good support for that.
For home users this all might be of very little importance, but in larger environments, where tb wants to have a chance to stand against outlook, a stable solution to share calendars and addresses is really necessary.