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

[David Woodhouse <dwmw2 infradead org>]

On Tue, 2011-05-17 at 14:04 +0200, Patrick Ohly wrote:
> On Di, 2011-05-17 at 12:38 +0100, David Woodhouse wrote:
> > 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.

[EDS upstream]

I have no objection to an *optimisation*. You seemed to be describing a
*fix*, not an optimisation.

An *optimisation* allows things to work faster or more efficiently, when
they were already working before.

So if you expose an extra '32bit-numeric-uid' in your static
capabilities for the back end, and the user can make use of that to
operate more efficiently by bypassing the permanent uidstring<->integer
mapping, then I'm happy with that. But *only* if it really is an
optimisation, and designed such that the code still works (via the
mapping) without it.

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

[MeeGo]

As long as it's designed correctly upstream in EDS (i.e. a capability
rather than a blind assumption about the back end's behaviour), I would
reluctantly tolerate a temporary state in MeeGo 1.2 where we *only*
support back ends with that capability set. As long as the real mapping
support is forthcoming for MeeGo 1.3, because we *have* to support other
back ends there.

-- 
dwmw2