Re: [Evolution-hackers] 32 bit IDs in contact file backend
- From: Milan Crha <mcrha redhat com>
- To: evolution-hackers gnome org
- Subject: Re: [Evolution-hackers] 32 bit IDs in contact file backend
- Date: Wed, 18 May 2011 07:34:32 +0200
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? 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? 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?
Maybe I'm just too confused.
> > Your interface between QtContacts and eds may hide this QtContacts
> > implementation detail, to be able to support any book backend,
> > current or future. This might not be done in eds backend itself,
> > from my point of view.
>
> "might not" or "must not"?
Well, I'm not a maintainer of eds, this is only my personal opinion on
the subject.
Bye,
Milan
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]