Re: [Evolution-hackers] 32 bit IDs in contact file backend

2011-05-18 Thread Chenthill
On Tue, 2011-05-17 at 15:59 +0200, Patrick Ohly wrote: On Di, 2011-05-17 at 18:49 +0530, Chenthill wrote: On Tue, 2011-05-17 at 14:51 +0200, Patrick Ohly wrote: | Further work if you agree in principle: | * let clients query whether all contacts have the simplified ID - |

Re: [Evolution-hackers] 32 bit IDs in contact file backend

2011-05-18 Thread Patrick Ohly
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

Re: [Evolution-hackers] 32 bit IDs in contact file backend

2011-05-17 Thread Patrick Ohly
On Do, 2011-04-28 at 15:16 +0200, Patrick Ohly wrote: Attached the resulting patch. Note that with the patch applied, all new contacts in a Berkley DB get the simpler IDs, unconditionally. Older contacts continue to use their existing IDs. Would something like this be acceptable upstream? Any

Re: [Evolution-hackers] 32 bit IDs in contact file backend

2011-05-17 Thread David Woodhouse
On Thu, 2011-04-28 at 15:16 +0200, Patrick Ohly wrote: As part of wrapping QtContacts around EDS [1] I ran into the same issue that Nokia already encountered in their Maemo 5 [2] backend: EDS uses strings as ID, QtContacts 32 bit integers. Nokia solved that by setting up an in-memory hash

Re: [Evolution-hackers] 32 bit IDs in contact file backend

2011-05-17 Thread David Woodhouse
On Tue, 2011-05-17 at 14:51 +0200, Patrick Ohly wrote: 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

Re: [Evolution-hackers] 32 bit IDs in contact file backend

2011-05-17 Thread Chenthill
On Tue, 2011-05-17 at 14:51 +0200, Patrick Ohly wrote: 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

Re: [Evolution-hackers] 32 bit IDs in contact file backend

2011-05-17 Thread Patrick Ohly
On Di, 2011-05-17 at 18:49 +0530, Chenthill wrote: On Tue, 2011-05-17 at 14:51 +0200, Patrick Ohly wrote: | 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

Re: [Evolution-hackers] 32 bit IDs in contact file backend

2011-05-17 Thread Milan Crha
On Tue, 2011-05-17 at 15:59 +0200, Patrick Ohly wrote: I haven checked if other backend's would need this virtual function though. Maybe webdav might use it ? And then what? Build and maintain out-of-tree MeeGo versions of all backends? Quite frankly, patching the existing backends sounds

Re: [Evolution-hackers] 32 bit IDs in contact file backend

2011-05-17 Thread Patrick Ohly
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

Re: [Evolution-hackers] 32 bit IDs in contact file backend

2011-05-17 Thread Milan Crha
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

[Evolution-hackers] 32 bit IDs in contact file backend

2011-04-28 Thread Patrick Ohly
Hello! As part of wrapping QtContacts around EDS [1] I ran into the same issue that Nokia already encountered in their Maemo 5 [2] backend: EDS uses strings as ID, QtContacts 32 bit integers. Nokia solved that by setting up an in-memory hash which maps the UID string to its CRC-16. I don't see