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

[Chenthill <pchenthill gmail com>]

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 like EWS
> > > > with this setup, that would be entirely the wrong thing to do, surely?
> > > 
> > > I'm not so sure. We are pitching EDS as an alternative for other storage
> > > solutions that are highly optimized (= limited!) for specific use cases.
> > > What you are suggesting is that any attempt to add optimizations for a
> > > specific combination of app + EDS + backend is wrong and should be
> > > avoided. My feeling is that EDS will simply not be used at all unless
> > > such optimization are acceptable.
> > 
> > [EDS upstream]
> > 
> > I have no objection to an *optimisation*. You seemed to be describing a
> > *fix*, not an optimisation.
> > 
> > An *optimisation* allows things to work faster or more efficiently, when
> > they were already working before.
> > 
> > So if you expose an extra '32bit-numeric-uid' in your static
> > capabilities for the back end, and the user can make use of that to
> > operate more efficiently by bypassing the permanent uidstring<->integer
> > mapping, then I'm happy with that.
> 
> That was the plan. From the original email:
> 
> |  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 was for a moment confused on this and david's reply was right on
target :)

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 ?

- Chenthill.
> > But *only* if it really is an
> > optimisation, and designed such that the code still works (via the
> > mapping) without it.
> 
> I can't promise that the code will work without it right away because
> the mapping hasn't been implemented yet due to lack of time. See also:
> http://lists.meego.com/pipermail/meego-dev/2011-May/483078.html
> 
>