Re: [Evolution-hackers] Heads-up: EBookBackend/EBook ECalBackend/ECal ongoing API changes
On Thu, 2010-07-01 at 14:42 +0200, Patrick Ohly wrote: > 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". Hi, I finally updated the bug report with all the changes I did. As you and Chen suggested, the old API in EBook/ECal and EBookView/ECalView is still there, just deprecated by E_BOOK_DISABLE_DEPRECATED/E_CAL_DISABLE_DEPRECATED defines. See the bug [1] for more information what I would like to change. Bye, Milan [1] https://bugzilla.gnome.org/show_bug.cgi?id=623204 ___ 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 12:43 -0400, Matthew Barnes wrote: > 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. Hi, yes, correct, and the "cal-opened" signal in ECal. (See my reply to Patrick's email.) > 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. Well, you named pretty much everything what is common, there's nothing more, and error reporting is already in there, as ECal uses GError in the front end, same as synchronous API for EBook. There is one difference in ECal, it can report backend error message in any time, and it's propagated through signal to listeners on ECal object. From my point of view we are talking about approximately two functions and few signals being common for them both, which, I thing, doesn't worth the effort. And the async API can be done even without EClient, right? Just my opinion. Maybe take it in a separate bug. 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 17:55 +0200, Patrick Ohly wrote: > 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). Hi, for EBook it's "only" asynchronous API callbacks signature change, for example from: typedef void (*EBookCallback) (EBook *book, EBookStatus status, gpointer closure); will be now: typedef void (*EBookCallback) (EBook *book, const GError *error, gpointer closure); and with ECal it seems only the "cal_opened" signal signature change, from void (* cal_opened) (ECal *ecal, ECalendarStatus status); to void (* cal_opened) (ECal *ecal, const GError *error); Otherwise the EBook/ECal API would stay the same. > 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? Yes, Chen asked me the same when I told him about my intention about this change. Seeing the impact I would say that I can define E_BOOK_DISABLE_DEPRECATED and E_CAL_DISABLE_DEPRECATED and deprecate old API with new functions, though any backend will be broken, though with such a change we cannot do anything anyway. The only thing is about naming, would it be OK to use signal name like "cal-opened-ex" and callback names EBookCallbackEx, with, for example, e_book_async_open_ex? I would like to use "Ex" suffixes, as it makes more sense than for example "with_error" or "Error" suffix, which might indicate something quite different. > 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. Yup, I agree. 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: > 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
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: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 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 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 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)? Greetings, Christian -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48Fax: +49-271-771091-19 D-57072 Siegen http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
