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

[Patrick Ohly <patrick ohly gmx de>]

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 in
> > |        the e-client API thread; avoids reading all contact (UIDs)
> This sounds like a better solution than adding constraints on eds end.

I prefer to think of it as an additional promise to the libebook user,
not a constraint.

> One possibility which came to my mind [requires more thoughts] was to
> bring the uid generation (e_book_backend_file_create_next_uid) function
> into EBookBackend as a virtual function. Then you could have a external
> backend for qtcontacts subclassing EBookFileBackend and over-riding the
> create_next_uid function alone. 
> 
> 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 less
risky to me. Of course, including these changes upstream would be best.

-- 
Bye, Patrick Ohly
--  
Patrick Ohly gmx de
http://www.estamos.de/