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 -- [email protected] http://www.estamos.de/ _______________________________________________ evolution-hackers mailing list [email protected] To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
