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