Re: [Evolution-hackers] 32 bit IDs in contact file backend

[David Woodhouse <dwmw2 infradead org>]

On Thu, 2011-04-28 at 15:16 +0200, Patrick Ohly wrote:
> As part of wrapping QtContacts around EDS [1] I ran into the same issue
> that Nokia already encountered in their Maemo 5 [2] 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 Woodhouse intel com                              Intel Corporation