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 _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers