Nightingale - Nascent Contacts project under Thunderbird

R Kent James kent at
Fri Dec 2 18:21:39 UTC 2016

There's been some rumblings about forming a project to rewrite the
Address Book/Contacts part of Thunderbird. I'd like to propose a name,
and give some of my goals to see if they click with anyone else.

First, a name. I view this project as the Thunderbird equivalent of
Firefox's Servo project, so I wanted a parallel name that implied bird
and mechanical gizmo.  A couple of minutes of Googling led me to
"Nightingale". Wikipedia has this to say: "/The Nightingale/ (Danish:
/Nattergalen/) is a literary fairy tale by Hans Christian Andersen about
an emperor who prefers the tinkling of a bejeweled mechanical bird to
the song of a real nightingale. When the Emperor is near death, the
nightingale's song restores his health." Sounds appropriate to me!

So, what are the goals of Nightingale? Let's imagine a vibrant future
for Thunderbird. Although I think that the heart of Thunderbird needs to
always be a robust full-featured desktop app, the data and workflows
that users develop using Thunderbird need to also work in the
multi-platform environment that a typical user accesses regularly. I
myself use a powerful desktop during the day, Android tablets after
hours, an Android phone while on the move, and a Microsoft Surface
tablet while traveling. Currently, Thunderbird workflows do not
translate to environments outside of the powerful desktop.

So at least one goal for me of Nightingale is to test an environment
where the underlying data and workflows could be represented in all of
these environments. I'm proposing the Contacts portion of Thunderbird as
a testbed for how we might organize an app that met all of these
requirements. Similar to the Servo experiment under Firefox, the
expectation is not that Nightingale becomes Thunderbird, but that the
lessons learned in Nightingale (including possibly much of the code)
could eventually end up in Thunderbird to improve it.

I'd like to make sure we can run in these environments:

1)    As a component of a larger desktop app (the current Address Book
prototype that the NZ students and Guenter Wahl did for example runs as
an addon under Thunderbird).

2)    As a standalone desktop app (similar to how Sunbird used to be
supported for calendaring). Possibly under Electron?

3)    As components of a website.

4)    As a mobile-friendly app (possibly for example designed as a
Progressive Web App).

Why Contacts as a start? Because it is the simplest part of Thunderbird,
and also the most neglected.

Technology? At the moment, Thunderbird is reaching a crossroads where we
will need to decide on a new platform direction. One possibility is to
follow Firefox into the world of Rust. Another is to completely switch
platforms to some alternative, such as .NET Core or QT. But I think that
the path we have been implicitly following is to rewrite Thunderbird
using web technologies to the greatest extent possible. This is the path
that Nightingale will further explore.

We each have our personal motivations of why we are involved with open
source. For me, the motivation for Nightingale is to provide
opportunities for my students under what I will call the Caspia project
to get experience that will help them learn things they need to get a
job, as well as present that work to employers. I have one class
starting in January (and possibly two) that will hopefully focus on this
project. The students need to learn transportable skills, so fixing
legacy problems in Thunderbird using XUL and XPCOM is not really a
viable education project for them, but Nightingale is. It's also
important that the work be easily presentable to others, which means
Github and other hacker sharing sites, and not the relatively isolated
Mozilla ecosystem.

A big part of Contacts is dealing with many different sources.
Nightingale needs to access a wide variety of contact sources, including
Carddav, Google Contacts, Active Directory (LDAP), and Exchange Web
Services, and possibly myriad others (Facebook, Twitter, or whoever else
has a contacts API). A lot of the work will be adapting to these
different contact sources. Initially though the focus will probably be
on a very simple app that works in many environments, and has core
issues addressed like testing, error logging, building, etc.

Questions, comments, and contributors are welcome.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the tb-planning mailing list