<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>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.</p>
<p>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: "<i>The
Nightingale</i> (Danish: <i>Nattergalen</i>) 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!</p>
<p>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.</p>
<p>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.</p>
<p>I'd like to make sure we can run in these environments:</p>
<p>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).</p>
<p>2) As a standalone desktop app (similar to how Sunbird used to
be supported for calendaring). Possibly under Electron?<br>
</p>
<p>3) As components of a website.</p>
<p>4) As a mobile-friendly app (possibly for example designed as
a Progressive Web App).</p>
<p>Why Contacts as a start? Because it is the simplest part of
Thunderbird, and also the most neglected.</p>
<p>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.</p>
<p>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.</p>
<p>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.<br>
</p>
<p>Questions, comments, and contributors are welcome.<br>
</p>
<p>:rkent<br>
</p>
<p><br>
</p>
</body>
</html>