Re: [Evolution-hackers] Heads-up: EBookBackend/EBook ECalBackend/ECal ongoing API changes
On Thu, 2010-07-01 at 13:41 +0200, Christian Hilberg wrote: On Thursday 01 Juli 2010 at 08:58:32 Milan Crha wrote: Hi all, I'm working on a way to be able to report detailed errors from addressbook/calendar backends to UI, so users will be able to see something more sensible than just Other error message in Evolution. This is bug report for this [1], which I'm working on right now. [...] Are there any plans to backport this to Evo/EDS 2.30.x (I suppose not)? All freezes (api/abi/string/feature) etc. hold good with the stable branch (gnome-2-30 or 2.30.x). So we will not back-port. - Chenthill. Greetings, Christian ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Heads-up: EBookBackend/EBook ECalBackend/ECal ongoing API changes
On Thu, 2010-07-01 at 08:58 +0200, Milan Crha wrote: I'm working on a way to be able to report detailed errors from addressbook/calendar backends to UI, so users will be able to see something more sensible than just Other error message in Evolution. This is bug report for this [1], which I'm working on right now. Will that break libebook and libecal APIs? The issue only mentions backends, but the subject of your emails includes EBook and ECal. -- 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
Re: [Evolution-hackers] Heads-up: EBookBackend/EBook ECalBackend/ECal ongoing API changes
On Thu, 2010-07-01 at 14:42 +0200, Patrick Ohly wrote: Will that break libebook and libecal APIs? The issue only mentions backends, but the subject of your emails includes EBook and ECal. Hi, for EBook it is, all the async API there uses 'status' as an indicator of the operation result in the async callback. I'm changing it to GError too. I'm still on ECalBackend, but it seems some similar change will be in ECal too, though I'm not sure yet, I'm not that far. I'll summarize changes in the bug report when I'll be done with it, to have them written somewhere. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Heads-up: EBookBackend/EBook ECalBackend/ECal ongoing API changes
On Thu, 2010-07-01 at 14:57 +0200, Milan Crha wrote: On Thu, 2010-07-01 at 14:42 +0200, Patrick Ohly wrote: Will that break libebook and libecal APIs? The issue only mentions backends, but the subject of your emails includes EBook and ECal. Hi, for EBook it is, all the async API there uses 'status' as an indicator of the operation result in the async callback. I'm changing it to GError too. I'm still on ECalBackend, but it seems some similar change will be in ECal too, though I'm not sure yet, I'm not that far. I'll summarize changes in the bug report when I'll be done with it, to have them written somewhere. If this was about the synchronous APIs that SyncEvolution depends on, then I'd be really worried about this change. If those functions are not changed, SyncEvolution binaries from syncevolution.org will continue to work (full list of called functions attached). Having said that, are you sure that there is no way to preserve the old APIs? Perhaps the new implementation can be made available under a new name and the old one be implemented by mapping the GError to the old error code? I suspect that quite a few projects will have to adapt their source code if that's not the case. OpenOffice might be another candidate which tries to be binary compatible with different versions of Evolution. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ e_book_add_contact e_book_authenticate_user e_book_commit_contact e_book_error_quark e_book_get_addressbooks e_book_get_changes e_book_get_contact e_book_get_contacts e_book_get_supported_auth_methods e_book_get_uri e_book_new e_book_new_default_addressbook e_book_new_from_uri e_book_new_system_addressbook e_book_open e_book_query_any_field_contains e_book_query_unref e_book_remove_contact e_cal_add_timezone e_cal_component_get_icalcomponent e_cal_component_get_last_modified e_cal_component_get_type e_cal_create_object e_calendar_error_quark e_cal_get_component_as_string e_cal_get_object e_cal_get_object_list_as_comp e_cal_get_sources e_cal_get_timezone e_cal_get_uri e_cal_modify_object e_cal_new e_cal_new_from_uri e_cal_new_system_calendar e_cal_new_system_tasks e_cal_open e_cal_remove_object e_cal_remove_object_with_mod e_cal_set_auth_func ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Heads-up: EBookBackend/EBook ECalBackend/ECal ongoing API changes
On Thu, 2010-07-01 at 14:57 +0200, Milan Crha wrote: for EBook it is, all the async API there uses 'status' as an indicator of the operation result in the async callback. I'm changing it to GError too. I'm still on ECalBackend, but it seems some similar change will be in ECal too, though I'm not sure yet, I'm not that far. I'll summarize changes in the bug report when I'll be done with it, to have them written somewhere. If I understand all this correctly, it looks like what's being done here is allowing backends to report both an error code and a detailed error mesage to the client library, rather than having to set some generic and often less-than-helpful message from an error code alone. Looks like most of the impact in libecal and libebook is in the callback function signatures for asynchronous operations. The synchronous APIs will remain unchanged AFAICT. Chen/Milan: correct me if I'm wrong. You know, this might be a good time to starting talking again about a common base class for ECal and EBook. That would allow us to resolve some of the stupid inconsistencies between the two classes for common operations like opening, online/offline mode, ERROR REPORTING (ties into this thread), server crash detection, etc. It would also let us rewrite some of the async ops GIO-style. The window for API cleanups and ABI breaks in these libraries is closing fast. We could at least rough in a common base class now with a private data section and get the ECal/EBook ABI break out of the way. Then add API to it later. I had the name EClient in mind for the base class: GObject | +-- EClient (implements GInitable) | +-- EBook | +-- ECal ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
