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.o...@gmx.de
http://www.estamos.de/


_______________________________________________
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Reply via email to