Re: [Evolution-hackers] 32 bit IDs in contact file backend
- From: Patrick Ohly <patrick ohly gmx de>
- To: David Woodhouse <dwmw2 infradead org>
- Cc: Evolution Hackers <evolution-hackers gnome org>
- Subject: Re: [Evolution-hackers] 32 bit IDs in contact file backend
- Date: Tue, 17 May 2011 14:51:27 +0200
On Di, 2011-05-17 at 13:27 +0100, David Woodhouse wrote:
> 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.
That was the plan. From the original email:
| Further work if you agree in principle:
| * let clients query whether all contacts have the simplified ID -
| could be done with the dynamic capabilities that I mentioned in
| the e-client API thread; avoids reading all contact (UIDs)
> But *only* if it really is an
> optimisation, and designed such that the code still works (via the
> mapping) without it.
I can't promise that the code will work without it right away because
the mapping hasn't been implemented yet due to lack of time. See also:
Bye, Patrick Ohly
Patrick Ohly gmx de
] [Thread Prev