<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 09/02/2011 23:34, Joshua Cranmer wrote:
<blockquote cite="mid:4D53246D.4090700@verizon.net" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
On 02/08/2011 04:26 PM, Mark Banner wrote:
<blockquote cite="mid:4D51B4F0.90207@mozillamessaging.com"
type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<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>
</blockquote>
This may be a bit nit-picky, but, particularly in the case of
operating system address books, there are three different kinds of
integration:<br>
1. Expose the OS address book as an additional address book<br>
2. Use the OS address book as the primary address book<br>
2a. Expose a system address book backend API to access the primary
address book [1]<br>
3. Synchronize the OS address book with the primary address
book[s] (more useful for cloud-based address books, I think).<br>
<br>
Which kind of integration did you mean?<br>
</blockquote>
Probably some of the above.<br>
<br>
With reference to item 1 I think in the long term we don't want the
concept of multiple address books within the address book. Its
generally confusing and doesn't seem to fit well with managing
contacts across multiple data sources, or even just within
Thunderbird itself.<br>
<br>
Item 2 has been mentioned a few times, and it may fit better in some
circumstances rather than others, but it is an area to possibly
experiment in.<br>
<br>
Item 3 is also a possibility and could, for example, operate in a
cloud-based style, a bit like the contacts extension is doing.<br>
<br>
<blockquote cite="mid:4D53246D.4090700@verizon.net" type="cite">
<blockquote cite="mid:4D51B4F0.90207@mozillamessaging.com"
type="cite">
<div class="ace-line" id="magicdomid1285">
<ul>
</ul>
</div>
<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
moz-do-not-send="true"
href="https://mozillalabs.com/contacts/">various</a> <a
moz-do-not-send="true"
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> </blockquote>
I know one thing that was mooted at some point was making the
current Thunderbird APIs closer to the contacts API. While it
would probably be a bad idea to fully switch to the API, would it
be a worthy experiment to include the API in TB for the next
version or so, to see what extension authors think of it?<br>
</blockquote>
I believe the contacts API is still in development so it wouldn't
necessarily make sense to do that yet. Additionally, I think we need
to be clearer on where we want the user experience to go (by
collecting data, doing experiments as I said in the main email),
before we start bringing in totally new APIs, otherwise we run the
danger of having something which still doesn't quite fit what we
want. Whilst it may fit in future, we need to gain some
understanding to make that assessment.<br>
<br>
Mark.<br>
</body>
</html>