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

[Chenthill <pchenthill gmail com>]

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 -
> > > |        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?
Well, if you were thinking on supporting all backends using Qtcontacts,
it is never a solution. I suggested looking at the initial patch
attached, which meant only for file backend. Changing the ids to use 32
bit ids just for file backend also becomes irrelevant if the intention
is to support all backends, as its clear that servers like
exchange/groupwise create uids as strings which cannot be controlled by
eds.

>  Quite frankly, patching the existing backends sounds less
> risky to me. Of course, including these changes upstream would be best.
I agree, but we need to find a better solution than the one which is
proposed to suit all backend's.

- Chenthill.