On Mo, 2011-06-06 at 08:41 +0100, Dumez, Christophe wrote: > > These collision-safe hash IDs are not necessarily stable > across > reopening QtContacts, are they? > [...] > > 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).
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. > Considering there is a very easy and efficient fix for EDS, this > seems a bit "overkill" IMHO. The goal is to have this working in MeeGo with other EDS backends. David's use case was the Exchange Web Services backend. Whether that'll work in practice depends on other factors, too, like how well these backends support storing arbitrary X- extensions and their filtering support. But without hashing, it won't work at all. > 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. See above. With EDS, we cannot make compile time assumptions about the backend. > 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? That would be wrong because libebook might be used to access a non-file backend. -- 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
