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

[Milan Crha <mcrha redhat com>]

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 calls g_cancellable_cancel().
> 
>    The following functions should be dropped from the public API:
> 
>      e_client_cancel_op()
>      e_client_register_op()
>      e_client_unregister_op()
> 
>    All functions that kick off an asynchronous operation should return
>    "void".  If you need to use numeric IDs to track D-Bus operations,
>    do so internally.  Create an "e-client-private.h" if you need to.
>    Don't expose it in the public API.

I was afraid of an overuse of the GCancellable, as it is used for the
DBus communication and then for the whole operation lifetime too. But
you've right, both ways are probably not needed.


> 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 to authentication signals and then implement the
>    keyring lookup and user password prompting yourself.
> 
> ...
>    The benefit here is that apps can simply pass some pre-packaged
>    ECredentials implementation when creating calendar or address book
>    connections and not have to worry about handling authentication
>    beyond that.
> 
>    The ECredentials API you came up with would be one possible
>    implementation of the raw ECredentials interface illustrated above.
>    It should live in libedataserverui or maybe just in Evolution so it
>    can run a password dialog or whatever other GTK-related things it
>    may need to do.

Please see libedataserverui/e-client-authenticate.*. It does that. The
ECredentials is also used in authenticate_user backend implementations,
allowing ask for any backend (as you cannot ask for a password for an
address book from a contact calendar backend right now), and one is also
able to ask for a PIN, as was asked for by the kolab developers.

I covered your requirements and (at least) those two above in a simpler
way, at least for me.

> 3) The "new" functions for EClient classes should be asynchronous, and
> ...
>    I'd really like for establishing a D-Bus connection to the backend,
>    connecting to a remote server, and authenticating via ECredentials to
>    be *one* step for the app.  It either all works and you get back a
>    fully connected and authenticated EClient object, or something fails
>    and you get back NULL with a GError set.
> 
>    I want to avoid these weird in-between states where you're holding a
>    client object but you haven't connected to the backend yet, or you
>    failed to authenticate with the remoter server, etc.  It just makes
>    life difficult and confusing for apps trying to figure what they're
>    supposed to do in these cases.
> ...

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 notified "open-done", or after, it depends. What
about offline mode? What about offline server which requires
authentication when evolution is online? (The CalDAV calendar backend
deals with that case, somehow.)

I agree that invoking operations on backends which are opened but not
authenticated yet leads to issues, bugzilla shows "couple" of them, but
I seem to miss here something too.

	Milan