On Mon, 06 Jun 2011 13:38:29 +0200, Patrick Ohly wrote:
On Mo, 2011-06-06 at 13:34 +0200, Patrick Ohly wrote:
On Mo, 2011-06-06 at 11:55 +0100, Adrien Bustany wrote:
> On Mon, 06 Jun 2011 10:36:22 +0200, Patrick Ohly wrote:
> > On Mo, 2011-06-06 at 08:41 +0100, Dumez, Christophe wrote:
>
> <snip>
>
> >
> > I believe that QtContact IDs are meant be stable across
restarts.
> > Syncing based on the QtContacts API relies on that, for example
(both
> > Buteo and SyncEvolution). We might get away with it with the
current
> > set
> > of apps using QtContacts, but there is no guarantee that it will
work
> > with all apps.
>
> QContactId is just manager uri + QContactLocalId. QContactLocalId
> should
> not be stored by programs, because it can change from one run to
> another. For synchronization purposes, you might want to consider
using
> QContactGuid.
>
> <snip>
Oh, that's good to know. Thanks for clarifying this. I don't
remember
where I got the (wrong) idea from. Too much exposure to EDS, I
suppose,
where the IDs are stable ;-}
Hmm, I wonder whether app developers are aware of this. It implies
that
passing QContactId between processes is not correct, because these
IDs
are only valid inside the process.
Connie, how are contacts references inside the MeeGo UX (for things
like
"show contact XYZ")? QContactId or QContactGuid?
Hmm that would still be correct I guess, but you'd have to check with
the mobility developers... I wouldn't expect the DB to change the ids
for one same contact from one program to another, but I wouldn't expect
the DB to keep local ids valid from one DB session to another (for
example with Tracker, we sometimes have to rebuild the DB if the schema
changed → IDs can be invalidated). Also, I'm not totally sure if
QContactGuid is mandatory, if not it makes things even more tricky :/
Cheers
Adrien
_______________________________________________
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
