On Thu, 2011-04-28 at 15:16 +0200, Patrick Ohly wrote: > As part of wrapping QtContacts around EDS  I ran into the same issue > that Nokia already encountered in their Maemo 5  backend: EDS uses > strings as ID, QtContacts 32 bit integers. > > Nokia solved that by setting up an in-memory hash which maps the UID > string to its CRC-16. I don't see any checks for the (possible) hash > collisions. IMHO a proper solution has to keep a permanent mapping on > disk, otherwise the 32 bit IDs won't be stable. > > Overall not a nice solution. My attempt to make it nicer at least in > combination with the file backend (the main goal for QtContacts-EDS) > focused on simplifying the problem instead: with 32 bit IDs in the > storage, the mapping becomes easy.
While I understand what you're saying when you say 'nicer', this seems to be a fundamentally *wrong* approach. You're suggesting that a user of the EDS API should rely on internal implementation details of a single back end, which don't even apply to other back ends. Even if we *didn't* have immediate plans to use other back ends like EWS with this setup, that would be entirely the wrong thing to do, surely? Or is this hack planned to be *extremely* limited for MeeGo 1.2, and dropped in some way (perhaps by *fixing* the QtContacts API) by 1.3? In which case, perhaps it really would make more sense to do it with a persistent mapping in your wrapper? -- David Woodhouse Open Source Technology Centre david.woodho...@intel.com Intel Corporation _______________________________________________ evolution-hackers mailing list email@example.com To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers