<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="ace-line" id="magicdomid1170"><span class="">At </span><span
class="author-g-hnfb38hyas63j2q1">the recent</span><span
class=""> all-hands, we had several discussions touching on the
address book. We've been struggling with what to do with the
address book - whilst it feels that it needs some significant
rework, especially in the back-end, there's a big question of
what to rework it in to and how.</span></div>
<div class="ace-line" id="magicdomid1172"><br>
</div>
<div class="ace-line" id="magicdomid1285"><span
class="author-g-s2ebflgv0cuguexb">Thunderbird's address book is
critically useful to Thunderbird's operations today. There are
also areas in which many improvements are possible. Those areas
include:</span><span class="author-g-s2ebflgv0cuguexb"><br>
</span>
<ul>
<li><span class="author-g-s2ebflgv0cuguexb">Improving the
database schema for individuals, to accommodate an evolution
in the kinds of information that users want to keep about
their contacts (e.g. more & different fields, more
values per fields)</span></li>
<li><span class="author-g-s2ebflgv0cuguexb">Better integration
with other sources of contact data, whether corporate (e.g.
LDAP servers), operating system provided, or web &
cloud-based systems.</span></li>
</ul>
</div>
<div class="ace-line" id="magicdomid2196"><span
class="author-g-ml4jrkbwmq5krsdt">More radically</span><span
class="author-g-s2ebflgv0cuguexb">, Thunderbird's address book
could be used as a generic mechanism to store a variety of kinds
of information about contacts, which could then be used by other
parts of the system (e.g. if we could tag contacts as 'friends',
'family', 'work', 'clients', etc., then there could be filtering
& prioritizing systems which could build on them). </span></div>
<div class="ace-line" id="magicdomid1592"><br>
</div>
<div class="ace-line" id="magicdomid1716"><span
class="author-g-s2ebflgv0cuguexb">It's also worth pointing out
that since Thunderbird 3 we also have a more modern database
system which includes some contact information as part of the
Gloda system, and that the current address book code is limited
in its flexibility.</span></div>
<div class="ace-line" id="magicdomid1717"><br>
</div>
<div class="ace-line" id="magicdomid1819"><span
class="author-g-s2ebflgv0cuguexb">In order to explore some of
the ideas described above while not destabilizing the current
use cases, we're proposing the following approach:</span></div>
<div class="ace-line" id="magicdomid1820"><br>
</div>
<div class="ace-line" id="magicdomid1899"><span
class="author-g-s2ebflgv0cuguexb">1) In the short term, we will
consider selected improvements to the existing code-base that
address the most painful limitations of today's address book
while minimizing the risk of regressions. We've identified two
such candidates:</span><span class="author-g-s2ebflgv0cuguexb"><br>
</span>
<ul>
<li><span class="author-g-s2ebflgv0cuguexb"><a
href="https://wiki.mozilla.org/MailNews:Address_Book/Multiple_Email_Addresses">Allowing
more than two email addresses per contact</a><br>
</span></li>
<li><span class="author-g-s2ebflgv0cuguexb"><a
href="https://wiki.mozilla.org/MailNews:Address_Book/Merging_Contacts">Merging
of contacts</a><br>
</span></li>
</ul>
</div>
<div class="ace-line" id="magicdomid2282"><span
class="author-g-ml4jrkbwmq5krsdt">There may also be more that
we'll encourage as appropriate. The linked wiki pages are place
holders with just some basic off-the-cuff notes, we'll flesh
those out more as we move forward.</span></div>
<div class="ace-line" id="magicdomid1904"><br>
</div>
<div class="ace-line" id="magicdomid2192"><span
class="author-g-s2ebflgv0cuguexb">2) In parallel, we encourage
experimentation on alternative address books from contributors
of all kinds. We believe that it should be possible to create
completely new address books for Thunderbird using the add-on
model, and that building and learning from those add-ons will be
the best way to identify successful outcomes, while not
destabilizing the current working system. If developers
encounter limitations in the APIs that prevent them from doing
that kind of experimentation, we would be interested in fixing
those in the platform.</span></div>
<div class="" id="magicdomid5"><br>
</div>
<div class="ace-line" id="magicdomid138"><span class="">There are
some existing efforts that have been looking at Contacts and
Contacts management on the internet</span><span
class="author-g-hnfb38hyas63j2q1"> (for example, the <a
href="https://mozillalabs.com/contacts/">various</a> <a
href="https://mozillalabs.com/messaging/thunderbird-contacts/">efforts</a>
on Mozilla Labs)</span><span class="">. We feel that it is worth
watching these as well as encouraging experimentation from
within the Thunderbird area.</span></div>
<div class="" id="magicdomid16"><br>
</div>
<div class="ace-line" id="magicdomid1169"><span class="">In the
longer term, we are going to be investigating the address book
use cases in more detail, looking to get some statistics, and
working out proposals for moving the user experience forward.</span><span
class="author-g-hnfb38hyas63j2q1"> This will then drive the
requirements for the back-end where we can decide in which
direction to go.</span></div>
<br>
Mark.<br>
</body>
</html>