[Qt-mobility-feedback] QContactManager, Telepathy and Meego

[christopher.adams at nokia.com]

Hi Gerry,

Unfortunately I'm not intimately familiar with the internals of contactsd, however I am told that at the moment it is only one-way (that is, syncs Telepathy to Tracker, not vice versa).  It is technically feasible but currently not planned, to enable bidirectional syncing.  I believe that one of the reasons why it's not currently planned, is that listening and reacting to changes in Tracker can be expensive.  Development is on-going, though, so it's possible that support for bi-directional syncing will be added in the future - perhaps even by an interested member of the community (contactsd is, after all, open source :-)

Cheers,
Chris.


>-----Original Message-----
>Chris:
>
>I will try to take a look at the QContactAction draft but it may be
>out-of-scope for what I am working on, so my experience may not apply.
>
>Thanks for the pointers to contactsd and qtcontacts-tracker, I was not
>aware of either of them.  They look promising.
>
>I briefly looked at contactsd, and as far as I can tell it appears to be
>one-way only.  That is, it reads Telepathy Contacts and puts them into
>tracker, but does not sync changes in the other direction
>(tracker-to-telepathy).  Is that correct?
>
>-Gerry
>
>On 07/19/2010 07:58 PM, christopher.adams at nokia.com wrote:
>> Hi Gerry,
>>
>> You are correct: in the Qt Mobility Contacts API sense, Telepathy is a
>store of contact information, which can be exposed through a contact
>engine backend.  Telepathy is more than simply a contact information
>store, though, as you mentioned.  In the Qt Mobility Contacts API, we
>don't intend to expose all of the possible functionality which is
>supported by Telepathy, as some of it is out of scope.
>>
>> However, for things like VoIP services (and other things), we are
>developing an API to allow users to request functionality on a contact
>or detail of a contact.  The current draft of the API can be found at:
>http://qt.gitorious.org/qt-mobility/contacts/commits/qtsw/qsfwactions
>>
>> This API is under active development, and your feedback would be
>valuable, if you are able to take a look at it.
>> In short, it allows third party service providers to provide
>"QContactAction" plugins via the Qt Service Framework (although it is
>opaque to the clients of the QContactAction API that the backend uses
>the service framework to populate QContactAction plugins).  We still
>have a bit of work to complete on it, mainly around defining some
>default actions and implementing those default actions on various
>platforms, but the API will be solidified in the very near future.
>>
>> For the 90% use-case, we think that these actions will suffice for
>clients.  There may be some situations or advanced uses where deeper,
>platform specific APIs must be used, of course.
>>
>> For Telepathy integration, there are two components (of which I'm
>aware) which can enable this:
>> 1) Contactsd
>>      - glue between Telepathy and Tracker
>>      - http://gitorious.org/qtcontacts-tracker/contactsd
>>
>> 2) qtcontacts-tracker Qt Mobility Contacts manager engine plugin
>>      - reads contact information from Tracker and presents it as
>QContact objects
>>      - http://gitorious.org/qtcontacts-tracker/qtcontacts-tracker
>>
>> Both of these projects are Work In Progress, as far as I know.
>>
>> Cheers,
>> Chris.
>>
>>
>>> -----Original Message-----
>>> I have a question on the scope of QT Moblity's contact management
>>> support.
>>>
>>> The QT Mobility QContact API supports contacts.  Telepathy also
>supports
>>> contacts for the various VOIP (as well as IM) services.  Both QT
>>> Mobility and Telepathy are supported on Meego, a core platform for QT
>>> Mobility.
>>>
>>> Does the QContact API support retrieving contacts from Telepathy (I
>>> presume through some contact engine backend)?  I could not find any
>>> reference to this capability existing.
>>>
>>> It appears that to handle VOIP services together with GSM services,
>one
>>> needs to deal with two contact API's (as well as two telephony api's
>but
>>> that's another issue...)
>>>
>>> Is this correct?
>>>
>>> Thanks
>>>
>>> -Gerry
>>>
>>