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 > > _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers