On Fr, 2011-05-20 at 13:45 +0100, Christophe Dumez wrote:
> > To be honest, I'd rather see the hash support *fixed* rather than
> > removed.
> >
> Hi,
>
> In response to David Woodhouse's feedback, please find attached a patch
> for QtContacts-EDS that implements thread-safe and collision-safe ID
> hashing to bring compatibility with unpatched EDS (that uses string ids).
> I would appreciate if you could review it before I merge the change.
These collision-safe hash IDs are not necessarily stable across
reopening QtContacts, are they?
What I mean is this:
1. Contact A and B have string IDs "A" and "B" whose hashes
collide.
2. Contact A gets integer ID 1, B gets 2 (after detecting the
collision).
3. App stores ID 2 and quits.
4. Contact A gets deleted by someone else (or even the app itself).
5. App restarts.
6. There's no hash collision anymore, so now contact B has integer
ID 1 => app gets confused because IDs changed.
I believe the only way to solve this is to introduce a permanent storing
of the in-memory hash, with all the complications that this introduces
(multiple processes need to maintain it collaboratively). I suspect that
this can only be done reliably in the EDS server.
The other conceptual problem with the patch is the compile time choice
between "hashing on and off". This needs to be a runtime check, so that
depending on whether we use a local file backend or something else the
right ID handling will be used. This in turn depends on the "IDs are 32
bit" capability check that we were discussing with the EDS developers -
that still needs to be added to EDS.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
