[#8410] contacts as a service
Summary contacts as a service
Queue Turba
Queue Version HEAD
Type Enhancement
State Accepted
Priority 1. Low
Requester chuck (at) horde (dot) org
Created 2009-07-05 (4461 days ago)
Patch No

2009-07-05 22:35:37 Chuck Hagenbuch Comment #1
Type ⇒ Enhancement
State ⇒ Accepted
Priority ⇒ 1. Low
Summary ⇒ contacts as a service
Queue ⇒ Turba
Milestone ⇒
Patch ⇒ No
Reply to this comment

Pre's approach to contacts is really the future of contact management. 
There's a part in my interview with Russ Daniels, HP's VP of Cloud 
Services Strategy, that I keep coming back to, where Russ is 
describing the hassle of syncing contacts between multiple devices; 
most of this hassle stems from the fact that devices tend to view your 
contacts database as pool of data, instead of a service.

What none of them do is the simple thing of, "tell me the URL for your 
contact service." Additionally, it has to be a service, not a 
repository, because in fact the contact information that's relevant 
for me includes the global address list for HP, and I have to be able 
to have that invoked... I can't replicate that data and keep it 
synchronized, so I need to be able to use a federation model behind 
this single endpoint to answer those kinds of queries.

The Pre is the first device I've used that expects all contact data to 
come from a service instead of a repository. Give it your Google, 
Facebook, Exchange, or AIM credentials, and it pulls all of the 
contacts for those services down onto the device. Ultimately, webOS 
presumes that the canonical source for your contact data is a cloud or 
server somewhere, and that your phone merely acts as a local cache for 
this data. (In fact, webOS's contact management is so service-oriented 
that it's kind of a pain to access a traditional contact 
repository?like a standard vcard collection, for instance.)

Saved Queries