On Di, 2011-05-17 at 12:38 +0100, David Woodhouse wrote:
> 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?

I'm not so sure. We are pitching EDS as an alternative for other storage
solutions that are highly optimized (= limited!) for specific use cases.
What you are suggesting is that any attempt to add optimizations for a
specific combination of app + EDS + backend is wrong and should be
avoided. My feeling is that EDS will simply not be used at all unless
such optimization are acceptable.

> 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?

There are no plans to fix the QtContacts API.

I agree that adding a mapping to QtContacts-EDS is useful and should be
done - eventually. Right now, the 32 bit EDS patch is the easiest (and
only) solution that we have for the problem. If there is no interest in
it upstream, then I would at least like to use it in MeeGo.

Bye, Patrick Ohly

evolution-hackers mailing list
To change your list options or unsubscribe, visit ...

Reply via email to