Re: [Evolution-hackers] 32 bit IDs in contact file backend
- From: Patrick Ohly <patrick ohly gmx de>
- To: Evolution Hackers <evolution-hackers gnome org>
- Subject: Re: [Evolution-hackers] 32 bit IDs in contact file backend
- Date: Wed, 18 May 2011 08:28:34 +0200
On Mi, 2011-05-18 at 07:34 +0200, Milan Crha wrote:
> On Tue, 2011-05-17 at 17:19 +0200, Patrick Ohly wrote:
> > On Di, 2011-05-17 at 16:25 +0200, Milan Crha wrote:
> > > On Tue, 2011-05-17 at 15:59 +0200, Patrick Ohly wrote:
> > > I'm not sure if I got it right, but such workarounds are just
> > > wrong from my point of view. You cannot force servers to use
> > > certain types of IDs because of constraints given by application
> > > which tries to connect to it.
> >
> > We can't force a server. But we can adapt the file backend.
>
> That's what I didn't get fully from your conversation with David. What
> is the gain to change file backend when there are all other backends
> which will be unusable with QtContacts because they cannot do 32-bit int
> UIDs?
Once we have the mapping, it is an optimization. Without the mapping, it
is the only way to get the system working.
> Was it "just" to have it done "natively" in the most common
> backend and all the rest will use mappings in the QtContacts<->EDS
> interface?
Yes.
> It might be harder to spot bugs in the first or the second
> part of the code (with or without intermediate mappings), isn't it?
This argument can be turned around: because we don't need the mapping
with the 32 bit patch applied, we can focus on the rest of the code,
test in a working system, and later extend it.
--
Bye, Patrick Ohly
--
Patrick Ohly gmx de
http://www.estamos.de/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]