The future of address books; not e-d-s

There has been some movement these days regarding the people project. There was a discussion on the google group, and a couple of blog posts; Ross Burton, Federico Mena, Phillip Van Hoof, and Johann Prieur.

Those discussions are too focused on old technologies. In a not too distant future some data portable web service is going to provide all the address book merging you might need, think linking your Gmail contacts, Facebook and some random phone numbers. Then you will want to put them on your mobile phone, and not waste bandwidth downloading all the contact information when only a few fields changed.

As expected, the web services are advancing much faster than desktop applications. Plaxo already does a good job keeping your address book, e-d-s UI’s on the other hand do a crappy job querying LDAP databases.

First of all, e-d-s is too Evolution specific, it’s not a standalone thing, it unnecessarily messes with calendars too. Also, you can’t just update the plug-ins or install new ones.

Federico Mena said:

E-d-s was always meant to be a local daemon to store your calendar and addressbook. It’s the local Model in a Model/View split for all the processes which want to access your calendar/addressbook data. It was also meant to act as a local cache for remote calendars, which could be slow/huge/etc — that is, for stuff which is far away or not in the same scale as your own little appointments.


It doesn’t matter if it’s local, or on some web service; clients should be able to transparently access different address books in different back-ends: Facebook, MSN Live, Plaxo, Gmail, sqlite, LDAP. It would be painful to develop all these back-ends in plain C, so something that can use back-ends developed in any language (Ruby? Python?) is required. A D-Bus interface should do it.

Think for example GNOME Do. You just type the name of the contact then you’ll have a list of actions to do with it. Maybe chat, send e-mail, check her v-card, visit Facebook profile, etc. The Galago project might help on the presence stuff (link to Pidgin, Telepathy, etc.)


It’s not enough to have access to different back-ends, sometimes you won’t have a fancy address book framework to find the right person. Your only device might be a mobile phone, so some synchronization API is required. Some back-ends would allow to fetch only the changes from the last sync, that’s efficient, but also specially useful when bandwidth is expensive.

Conduit would surely serve that purpose.

People Project

People Basic Architecture

What is required right now is to create a nice middle ware API, lots of back-ends, and lots of front-ends; experimentation. All the parts should evolve at the same time, otherwise the API won’t be as flexible as it’s required and would stay as staggered as the e-d-s one (ironic).

The people project is looking for contributions, so, if you are interested just join 😉 Even if it’s just to discuss ideas.


5 thoughts on “The future of address books; not e-d-s

  1. I remember some people mentioned before that EDS is not what you want – especially for the more and more networked mobile devices. Currently I do not have time to contribute, but I’ll watch the project and take a look from time to time.
    When desinging the whole thing don’t forget to keep it simple 🙂

  2. i like the sync from the apple iPhone with mac machines. only the contacts and new recent podcasts,telephone numbers sync. mobileme service will take it to the core but anyway it is a closed payed system from apple…not easy to bring this all together…

    dont buy cars, buy t-shirts!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s