Re: [Evolution-hackers] (what is done) New 'eclient' branch in eds

[Milan Crha <mcrha redhat com>]

        Hi,
I did following changes in the eclient branch:

a) Calendar's getFreeBusy notifies about components with a signal.
b) Merge common client error codes to E_CLIENT_ERROR (I still prefer
   place of the origin, so I also dropped few error codes, but otherwise
   didn't use any GIO error codes). Note this split to E_CLIENT_ERROR &
   E_BOOK_CLIENT_ERROR/E_CAL_CLIENT_ERROR will make things more
   difficult in error checking, as the one switch which is in evo
   sources now will be divided into two, based on the error domain now.
   Pity, isn't it?
c) Make async functions 'void' in EClient/EBookClient/ECalClient. I feel
   like loosing a feedback in those function, even it's only about
   coder's errors, but I changed it anyway.
d) Remove unnecessary 'const' qualifiers from structures in public
   EBookClient/ECalClient APIs. Together with it I made
   e_book_client_get_contacts and e_book_client_get_view not using
   EBookQuery, but const gchar *sexp, same as ECalClient does. With
   other structures I kept the 'const' in a comment, as I indicated
   in a previous mail.

I left the rest as is, mainly because:
e) Remove e_client_register_op()/e_client_unregister_op()
   * I kept them, because it's in a protected "section" (that's not my
   fault that we are using plain C instead of C++ where this can be done
   cleanly) and because they are used. The e_client_cancel_op() was
   kept hidden, as it is used by EClient itself in the background.
f) ECredentials is way too complex.
   * Under discussion, I'm happy with the structure, proposal to
   ECredentialsProvider, even the issue is that with massive changes to
   a different provider might mean patching each place of its usage,
   which is pretty bad idea (the actual signal-centric solution offers
   to deal with this in one place only, in eds itself).
g) The "new" functions for EClient classes should be asynchronous
   * Under discussion, proposed e_book_client_open_new() and
   e_cal_client_open_new() having just two parameters with
   the authentication callback, and their _finish() counterparts,
   returning opened and authenticated client or a GError (as requested).
h) Overlap between the new EClient API and the new ESource API
   * Let's have it there till Matt will commit his changes from account
   management branch - in that time the relevant (obsolete) functions
   can be removed, though from my point of view it'll be better to
   replace their body with proper equivalent, instead of forcing
   everyone know from where the sources are taken (note the actual
   API hides precisely that sources are from the GConf).
i) Use GList instead of GSList
   * No support from others on this, so I kept it GSList, because
   I prefer simplicity of single-linked list.
j) e_cal/book_client_error_to_string() still necessary?
   * Even the backend can write there their own error message, then
   some errors are created on the client side too, where are these
   functions used. I prefer to have these function with texts available
   now, rather than missing later.
k) "get_capabilities" functions in EClient, ECalClient and EBookClient?
   * This is answered in another mail. What I forgot to add there is
   that the comment on EBookClient/ECalClient get_capabilities functions
   mentions its intention and that the caller may prefer to use cached
   values provided by EClient itself.

I hope I didn't forget of anything. I'll only add few notices in async
backend functions about proper e-data-book/cal functions to be used to
finish the operation, to address, at least a bit, the need for comments
and then I think there is nothing blocking the changes to be propagated
to master and have them used in other modules for 3.1.1.

Feel free to correct me, if I'm mistaken.
        Thanks and bye,
        Milan

P.S.: I was sending this last Wednesday, but it seems it didn't get it
to the list for some reason, thus resending. This doesn't include
changes proposed by Patrick, as they came on Thurday