Re: [Evolution-hackers] New 'eclient' branch in eds

2011-06-15 Thread Patrick Ohly
On Di, 2011-06-14 at 07:38 -0400, Matthew Barnes wrote: On Tue, 2011-06-14 at 12:08 +0200, Patrick Ohly wrote: My two cents as a user of these APIs: having to deal with a major API change once is acceptable. Whether it is in 3.2 or 3.4 I don't really care. But having to rewrite code

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-06-14 Thread Patrick Ohly
On Do, 2011-06-09 at 12:25 -0400, Matthew Barnes wrote: On Thu, 2011-06-09 at 17:11 +0200, Milan Crha wrote: I hope not, I'm currently working on evo bits to be buildable with E_BOOK_DISABLE_DEPRECATED and E_CAL_DISABLE_DEPRECATED defined (eds is done, but I'm postponing it till I have evo

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-06-14 Thread Matthew Barnes
On Tue, 2011-06-14 at 12:08 +0200, Patrick Ohly wrote: My two cents as a user of these APIs: having to deal with a major API change once is acceptable. Whether it is in 3.2 or 3.4 I don't really care. But having to rewrite code both for 3.2 *and* 3.4 goes a bit too far. So if the account

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-06-09 Thread Milan Crha
On Thu, 2011-06-09 at 07:12 -0400, Matthew Barnes wrote: Since merging the account-mgmt branch will change nearly all client-side APIs in E-D-S including EClient, and since it would be wise regardless of my schedule to allow ourselves some extra time to tweak this brand new EClient API before

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-06-09 Thread Matthew Barnes
On Thu, 2011-06-09 at 17:11 +0200, Milan Crha wrote: I hope not, I'm currently working on evo bits to be buildable with E_BOOK_DISABLE_DEPRECATED and E_CAL_DISABLE_DEPRECATED defined (eds is done, but I'm postponing it till I have evo and the standard rest done as well). Having one API

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-06-09 Thread Milan Crha
(I cannot Ctrl+L the message) On Thu, 2011-06-09 at 12:25 -0400, Matthew Barnes wrote: On Thu, 2011-06-09 at 17:11 +0200, Milan Crha wrote: I hope not, I'm currently working on evo bits to be buildable with E_BOOK_DISABLE_DEPRECATED and E_CAL_DISABLE_DEPRECATED defined (eds is done, but

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-06-09 Thread Matthew Barnes
On Thu, 2011-06-09 at 18:40 +0200, Milan Crha wrote: By the way, thinking of your announcement, I hope you are fine if I'll finish this stop using deprecated Book/Cal API in evo as soon as possible and commit it, thus it'll have more testing (I'm pretty sure I'll introduce few regressions and

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-06-09 Thread Milan Crha
On Thu, 2011-06-09 at 13:15 -0400, Matthew Barnes wrote: Yes, please do get us using the async EClient APIs in Evolution ASAP. I can deal with the impact to the branch -- I don't expect it to be too severe. Thanks, I'll do that. Just the first transition will be about not using deprecated API,

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-06-09 Thread Matthew Barnes
On Thu, 2011-06-09 at 22:48 +0200, Milan Crha wrote: Thanks, I'll do that. Just the first transition will be about not using deprecated API, the second part of it, making calls async, is a very different task, as I go through calendar sources and see all the sync calls and the API being served

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-06-09 Thread Milan Crha
On Thu, 2011-06-09 at 17:07 -0400, Matthew Barnes wrote: On Thu, 2011-06-09 at 22:48 +0200, Milan Crha wrote: Thanks, I'll do that. Just the first transition will be about not using deprecated API, the second part of it, making calls async, is a very different task, as I go through calendar

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-05-23 Thread Milan Crha
Hi, I just committed changes from 'eclient' branch to eds' master branch. This will be part of evolution-data-server 3.1.2. I'll adapt evolution-exchange, evolution-mapi, evolution-groupwise and evolution-couchdb for the API and opening phase changes. Feel free to poke me if you've any

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-05-11 Thread Milan Crha
On Fri, 2011-04-29 at 07:24 -0400, Matthew Barnes wrote: On Fri, 2011-04-29 at 06:59 +0200, Milan Crha wrote: There was just a little problem with ECalView, which had 'client' property, which is referring to ECal, instead of ECalClient, and I was forced to invent different name for it. But

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-29 Thread Matthew Barnes
On Fri, 2011-04-29 at 06:59 +0200, Milan Crha wrote: There was just a little problem with ECalView, which had 'client' property, which is referring to ECal, instead of ECalClient, and I was forced to invent different name for it. But after a bit of sleeping and small thinking I might be wrong

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-28 Thread Patrick Ohly
On Mo, 2011-04-18 at 15:57 +0200, Milan Crha wrote: I just created a new branch 'eclient' in eds [1] where is added my work on the new API which will deprecate EBook/ECal. It is following glib/gio async pattern and, I believe, makes things more coherent. First of all, +1 for rethinking the

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-28 Thread Patrick Ohly
On Di, 2011-04-19 at 16:03 +0200, Milan Crha wrote: On Tue, 2011-04-19 at 09:27 -0400, Matthew Barnes wrote: There's a couple other simple things I forgot to mention yesterday. * We should add some padding to all the public class structs so we can add new class methods in the future

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-28 Thread David Woodhouse
On Thu, 2011-04-28 at 11:56 +0200, Patrick Ohly wrote: Are you saying that a soname version bump can and should be done in a backwards-incompatible way (= code compiled against older version no longer works with new lib)? That's a major pain for people trying to support multiple distros.

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-28 Thread Matthew Barnes
On Thu, 2011-04-28 at 11:56 +0200, Patrick Ohly wrote: First of all, +1 for rethinking the API. I'd like to suggest that besides modernizing the API we also take this opportunity to move more of EBook/ECal into a common core. Opening and listing databases don't have to be separate. Turn

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-28 Thread Matthew Barnes
On Thu, 2011-04-28 at 13:12 +0100, David Woodhouse wrote: As I understand it, an soname bump (from libfoo.so.5 to libfoo.so.6) should *only* be used for backwards-incompatible changes. Correct. One such example of a backwards-incompatible change is increasing the size of a public GObject

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-28 Thread Patrick Ohly
On Do, 2011-04-28 at 08:17 -0400, Matthew Barnes wrote: On Thu, 2011-04-28 at 11:56 +0200, Patrick Ohly wrote: First of all, +1 for rethinking the API. I'd like to suggest that besides modernizing the API we also take this opportunity to move more of EBook/ECal into a common core.

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-28 Thread Milan Crha
[please reply to the list only, it makes my life worse when you CC me] On Thu, 2011-04-28 at 08:17 -0400, Matthew Barnes wrote: It would mean EClient has to know that ECalClient and EBookClient exist in order to instantiate the right one for a given enum value. Normally in class design you

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-28 Thread Milan Crha
On Thu, 2011-04-28 at 11:56 +0200, Patrick Ohly wrote: * 32 bit IDs - check whether (read) or ensure that (write) IDs are 32 bit integers instead of strings, simplifies QtContacts-EDS [2]; I have a patch which reduces the size of IDs from 64 bit to 32 in the file

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-28 Thread Milan Crha
On Thu, 2011-04-28 at 16:37 +0200, Milan Crha wrote: On Thu, 2011-04-28 at 11:56 +0200, Patrick Ohly wrote: * 32 bit IDs - check whether (read) or ensure that (write) IDs are 32 bit integers instead of strings, simplifies QtContacts-EDS [2]; I have a patch which

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-28 Thread Matthew Barnes
On Thu, 2011-04-28 at 16:34 +0200, Milan Crha wrote: You obviously face of a circular dependency, so it's not doable in a clean way. Also because EClient is in libedataserver, EBookClient in addressbook/libebook and similarly ECalClient in calendar/libecal. Both descendants link to

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-28 Thread Milan Crha
On Thu, 2011-04-28 at 11:59 -0400, Matthew Barnes wrote: On Thu, 2011-04-28 at 16:34 +0200, Milan Crha wrote: You obviously face of a circular dependency, so it's not doable in a clean way. Also because EClient is in libedataserver, EBookClient in addressbook/libebook and similarly

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-28 Thread Matthew Barnes
On Thu, 2011-04-28 at 18:11 +0200, Milan Crha wrote: Yes, when I was changing server side data-views for book and cal, then if turned out that the D-Bus API is exactly the same except of the DBUS_PROXY_NAME and book/cal strings in a file. Thus having type param for both factories too,

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-28 Thread Matthew Barnes
On Thu, 2011-04-28 at 14:49 +0200, Patrick Ohly wrote: Please, let's avoid E_CLIENT_TYPE_CALENDAR. For people less familiar with Evolution terminology it is not clear whether this includes tasks. In Evolution, it doesn't, but in other contexts it does. For example, Nokia phones store events

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-28 Thread Milan Crha
On Thu, 2011-04-28 at 12:35 -0400, Matthew Barnes wrote: This may also be of benefit to Srini and his email-factory branch. I can imagine extending the enum to include E_CLIENT_TYPE_MAIL_STORE or something similar. Only the last thing for the enum values, I would personally prefer something

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-28 Thread Matthew Barnes
On Thu, 2011-04-28 at 21:16 +0200, Patrick Ohly wrote: Agreed, the library dependency issue is a problem. That could be solved by an utility library on top of libecal and libebook which offers the unified API. Or you could just write your own function in EvolutionSync. It's just a switch

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-28 Thread Milan Crha
On Thu, 2011-04-28 at 15:04 -0400, Matthew Barnes wrote: On Thu, 2011-04-28 at 19:53 +0200, Milan Crha wrote: Only the last thing for the enum values, I would personally prefer something with a prefix E_CLIENT_SOURCE_TYPE_... only to not have it confusion-able with E_CLIENT_TYPE constant.

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-26 Thread Milan Crha
On Fri, 2011-04-22 at 13:58 -0400, Matthew Barnes wrote: The idea though is that what we do now in e-passwords.c -- namely checking GNOME Keyring for a password and building and displaying our own password dialog to the user -- is *one possible* implementation of that simple abstract

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-26 Thread Chenthill
On Thu, 2011-04-21 at 08:32 +0200, Milan Crha wrote: On Tue, 2011-04-19 at 17:00 +0200, Milan Crha wrote: On Tue, 2011-04-19 at 19:39 +0530, Chenthill Palanisamy wrote: I would like you to a incorporate some change to the free/busy api. Some servers allow querying free/busy information

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-22 Thread Milan Crha
On Thu, 2011-04-21 at 12:51 -0400, Matthew Barnes wrote: On Thu, 2011-04-21 at 17:11 +0200, Milan Crha wrote: It's technically not passed in this function, it's a callback signature. :) It would be used as a signal handler for auth-required signal in the function, as I think of it right

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-22 Thread Matthew Barnes
On Fri, 2011-04-22 at 19:03 +0200, Milan Crha wrote: Yup, though it'll be (internally - aka in D-Bus) still a signal. This request of ECredentials object seems strange to me, because I understand the ECredentials as something which actually holds credentials, not something what is asking for

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-21 Thread Milan Crha
On Tue, 2011-04-19 at 17:00 +0200, Milan Crha wrote: On Tue, 2011-04-19 at 19:39 +0530, Chenthill Palanisamy wrote: I would like you to a incorporate some change to the free/busy api. Some servers allow querying free/busy information for multiple users at a time and the results appear in a

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-21 Thread Milan Crha
On Tue, 2011-04-19 at 13:12 -0400, Matthew Barnes wrote: Then I can pass that ECredentials object any time I need to create a new EClient. I just call e_cal_client_new() or e_book_client_new(), pass the ECredentials object along with some ESource, wait for the callback, and I'm done. I can

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-21 Thread Matthew Barnes
On Thu, 2011-04-21 at 08:41 +0200, Milan Crha wrote: void e_client_open_new (ESource *source, gboolean (* auth_cb) (EClient *client, ECredentials *credentials, gpointer user_data), gpointer user_data); gboolean e_client_open_new_finish (GAsyncResult *result, EClient **client, GError

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-21 Thread Milan Crha
On Thu, 2011-04-21 at 08:34 -0400, Matthew Barnes wrote: On Thu, 2011-04-21 at 08:41 +0200, Milan Crha wrote: void e_client_open_new (ESource *source, gboolean (* auth_cb) (EClient *client, ECredentials *credentials, gpointer user_data), gpointer user_data); gboolean

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-21 Thread Matthew Barnes
On Thu, 2011-04-21 at 17:11 +0200, Milan Crha wrote: It's technically not passed in this function, it's a callback signature. :) It would be used as a signal handler for auth-required signal in the function, as I think of it right now. Yeah I'd like to kill the auth-required signal too as I've

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-20 Thread Milan Crha
On Tue, 2011-04-19 at 19:02 -0400, Matthew Barnes wrote: On Tue, 2011-04-19 at 23:25 +0100, David Woodhouse wrote: Note the 'gboolean retrying' argument to the libsoup authenticate signal handler. We probably want to have something similar in the above API too, because that's what tells

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-19 Thread Matthew Barnes
On Tue, 2011-04-19 at 07:58 +0200, Milan Crha wrote: * In EBookClient, drop the 'const' qualifier from EContact arguments. Trying to use 'const' with GObjects is misguided and pointless. I've cursed at EIterator many times for this. Yet another thing I wanted to address was a clear

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-19 Thread Milan Crha
On Tue, 2011-04-19 at 09:27 -0400, Matthew Barnes wrote: Havoc Pennington kept having to answer this same type of thing in the early days of GLib/GTK+ when people would ask why the API never uses const in functions that take but don't modify a GObject and GLib data structure.

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-19 Thread Chenthill Palanisamy
On Mon, Apr 18, 2011 at 10:18 PM, Matthew Barnes mbar...@redhat.com wrote: On Mon, 2011-04-18 at 15:57 +0200, Milan Crha wrote: I just created a new branch 'eclient' in eds [1] where is added my work on the new API which will deprecate EBook/ECal. It is following glib/gio async pattern and, I

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-19 Thread Matthew Barnes
On Mon, 2011-04-18 at 15:57 +0200, Milan Crha wrote: I just created a new branch 'eclient' in eds [1] where is added my work on the new API which will deprecate EBook/ECal. It is following glib/gio async pattern and, I believe, makes things more coherent. There's a few other weightier issues

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-19 Thread Milan Crha
On Tue, 2011-04-19 at 19:39 +0530, Chenthill Palanisamy wrote: I would like you to a incorporate some change to the free/busy api. Some servers allow querying free/busy information for multiple users at a time and the results appear in a iterative fashion. The freebusy information of some

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-19 Thread Matthew Barnes
On Tue, 2011-04-19 at 16:03 +0200, Milan Crha wrote: No, not at all, EClient calls descendant's get_capabilities_sync on its own, when it's needed. The public get_capabilities API on descendants is sort of redundant in this case. It that case we should have: void

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-19 Thread Milan Crha
On Tue, 2011-04-19 at 10:40 -0400, Matthew Barnes wrote: 1) There's no need for apps to use numeric IDs to track asynchronous operations; GCancellable fills that role. GCancellable is the app's handle to the ongoing operation. If the app wants to cancel an unfinished operation, it

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-19 Thread Matthew Barnes
On Tue, 2011-04-19 at 18:37 +0200, Milan Crha wrote: Hmm, I think I understand, but I do not see clearly the point. Sometimes you do not know if the server requires the authentication, only after open, which will deliver (on idle) the auth-required signal, which can come before the backend

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-19 Thread David Woodhouse
On Tue, 2011-04-19 at 10:40 -0400, Matthew Barnes wrote: 2) ECredentials is way too complex. My intent for ECredentials was to have a self-contained authentication handling interface to avoid all the current nonsense with ECal and EBook where you have to always remember to connect

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-19 Thread Matthew Barnes
On Tue, 2011-04-19 at 23:25 +0100, David Woodhouse wrote: Note the 'gboolean retrying' argument to the libsoup authenticate signal handler. We probably want to have something similar in the above API too, because that's what tells the UI that it needs to ditch the existing remembered password

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-18 Thread Philip Withnall
Hey, I haven't had a chance to look at it all in detail, but two things strike me from a quick glance: • If we're following the GIO async pattern, why do the e_data_book_respond_*() functions still exist? • Please, please, please add some documentation to the new EDataBook. Trying to

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-18 Thread Milan Crha
On Mon, 2011-04-18 at 15:36 +0100, Philip Withnall wrote: I haven't had a chance to look at it all in detail, but two things strike me from a quick glance: • If we're following the GIO async pattern, why do the e_data_book_respond_*() functions still exist? Hi, the server part

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-18 Thread Matthew Barnes
On Mon, 2011-04-18 at 15:57 +0200, Milan Crha wrote: I just created a new branch 'eclient' in eds [1] where is added my work on the new API which will deprecate EBook/ECal. It is following glib/gio async pattern and, I believe, makes things more coherent. Thanks for posting this, Milan. I

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-04-18 Thread Milan Crha
On Mon, 2011-04-18 at 12:48 -0400, Matthew Barnes wrote: * There's some overlap between the new EClient API and the new ESource API that I'm working on. Some functions will need to be dropped once the new ESource API is in place, so I don't know if you want to do this now or wait. ...