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 _______________________________________________ evolution-hackers mailing list firstname.lastname@example.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers