> 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. >
You are right and I knew when implementing that this could be a problem. I chose not to handle it because it requires permanent storing (as you said) and maintaining this mapping can be tricky, especially because the apps are not required to go through QtContacts to interact with EDS. We also need to remember that the problem only occurs if there is a hashing collision and if the apps require the contact local id to me persistent upon restart (meaning that they store the local ids for some reason). Considering there is a very easy and efficient fix for EDS, this seems a bit "overkill" IMHO. > > 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. > > I don't believe this is the right solution. Doing the check at runtime, would of course be more reliable but it would also be less efficient. I believe that a better fix for this would be to edit your 32bits IDs patch for EDS so that it adds -DUSE_32BIT_IDS to libebook-1.2.pc. This way, I could easily detect that at compilation time in QtContacts-EDS. It would be reliable and efficient. What do you think? Kr, Christophe Dumez.
_______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
