Address Book - where are we going?

Leni at
Fri Feb 11 02:50:17 UTC 2011

On 9/02/2011 8:26 AM, Mark Banner wrote:
 > At the recentall-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.

I'd like to explore some of the bigger picture questions around 
addressbook.  Here are some (pretty raw) observations and assertions:

1. the present strategy looks like a continuation of the policy
    since tb2.  Summarised as: few new fields and churn in the api.

2. by way of feedback on that - perhaps other people found the tb3
    api useful but for me:
    a) the tb3 interfaces required a lot of new development work
    b) extended spike in support burden because of instability,
       that lasted maybe 6-12 months.

3. the policy of 'lets innovate around the UX before deciding
    about the back end' seems intuitively right but
    the experience of the past several years suggests that it
    leads nowhere.  Have any significant learnings emerged?
    Basic problem is that there are too few people able to
    utter the necessary incantations and the few wizards prefer
    to do other things.

4. In any case, how is the success or failure of different UX
    experiments going to inform or clarify the key strategic
    questions (below)?

5. The addressbook API represents 15 years of technical debt -
    a massive dead weight around the neck of developers who
    touch addressbook.

6. The debt has to either be paid or written off
    before there is significant progress.

7. The basic idea of the TB addressbook api - a uniform interface
    to a diversity of addressbook stores is flawed in conception
    and impossible to implement in practice.
    It's an experiment that has lived on far beyond it's time.

Thoughts around a roadmap out of the current hole:

8. concentrate on Thunderbird's internal contacts store for a while.
    Forget about integration with external stores for a bit.

9. bolt on a 21st century access model that "competes"
    with the current API.  You can't instantly deprecate the current
    API and everything that depends on it.  But you might be able to
    bolt on a new API that is simple and extensible.
    - sqllite
    - REST api modelled on Google Contacts API or Windows contacts API
      which are both very well done.  Particularly google.

10. schema and representation.  It really doesn't matter so long
     as it is extensible and there's a mechanism for determining

11. TB addressbook desperately needs a notion of "group" to subsume
     both mailing lists and directories and support better
     'social' integration.

12. innovate the UX using this new API.

13. circle back to explore integration with external contact stores.
     There's no easy answer.  Personally I think sync offers the best
     UX - rather than real-time interaction via API.
     Either way, the reality to be faced here is that there's
     a significant spike in maintenance costs as you integrate with
     interfaces that are beyond your control.  Do you have the
     resources to take that on?


More information about the tb-planning mailing list