Re: [Evolution-hackers] Heads-up: EBookBackend/EBook ECalBackend/ECal ongoing API changes

2010-07-07 Thread Milan Crha
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

2010-07-01 Thread chen
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

2010-07-01 Thread Patrick Ohly
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

2010-07-01 Thread Milan Crha
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

2010-07-01 Thread Patrick Ohly
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

2010-07-01 Thread Matthew Barnes
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