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.
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).