[Evolution-hackers] Distinguish interactive and non-interactive EClient-s

[Milan Crha <mcrha redhat com>]

        Hi all,
I'd like to bring this up for a wider audience to discuss possible
solutions to distinguish between interactive and non-interactive
EClient-s (EBookClient/ECalClient users).

A demand at [1] is to not expose user prompts, either for a password, or
when a server's SSL certificate needs attention (and we might find more
usages, like for any user-invoked synchronization activities, which is
not in sources yet, but it may be added one day). The request in [1] is
to not do the user prompts when for example the gnome-shell's calendar
server tries to open a calendar, but an error should be indicated to a
user in gnome-shell and once he/she opens an interactive client the user
prompt will be shown. The interactive client can be evolution itself,
but also any other client which will advertise itself as interactive,
which can include gnome-shell's calendar server as a re-try to open
after user clicks any hypothetical button in the clock's UI. It's to
avoid spontaneous user prompts after login.

It's just a rough summary of the [1], as I understand it.

One might also consider issues like:
a) if evolution will manage the user prompts, how will the gnome-shell's
   calendar notice the change and will be able to reopen the calendar
b) the gnome-shell's calendar re-try on a button click may open in the
   interactive mode, but then should turn back into non-interactive mode
c) because the factory reuses one backend for each client connected to
   it, then it should also extend its tracking structure to remember
   whether the opened mode is interactive or not.

There can be found probably more issues to consider.

Here comes my proposal:

Currently, the e_client_open_sync (it has its async variant) looks like
this:
   gboolean e_client_open_sync (EClient *client,
                                gboolean only_if_exists,
                                GCancellable *cancellable,
                                GError **error);
thus I suggest to turn 'only_if_exists' gboolean into:
     guint32 open_flags,
which could be a bit-OR of these flags (for now):
    enum {
        E_CLIENT_OPEN_FLAG_NONE = 0,
        E_CLIENT_OPEN_FLAG_ONLY_IF_EXISTS = (1 << 1),
        E_CLIENT_OPEN_FLAG_NON_INTERACTIVE_MODE = (1 << 2)
    }

This way we've a backward compatibility, only clients which would like
to be non-interactive will advertise it, others will work like before.

To be able to address the need to disable/enable interactive mode after
open, there might be added a boolean "property" 'interactive-mode' to
the client. Maybe it can replace the flag in the e_client_open() call
completely.

On the factory side, the open will fail if the password was not stored
in keyring, or is not usable, or any other user prompt during opening
phase would be needed, and an error will be returned.

How to advertise that the client had been opened to others, aka the
client is available now, I do not know. One option would be to
reincarnate "opened" signal, and instead of failing the e_client_open
call, open it in offline mode, like using only offline cache or
something, and start showing fresh events only after other client will
open the calendar fully. The thing is that the function cannot return
warnings, it can return only errors, which indicates a failure.
Thus the offline mode is probably the right way. It still would be nice
to give a feedback why the book/cal had been opened in the offline mode,
because there can be many reasons for it, from password issues, through
SSL certificate prompts, down to servers being temporarily unavailable.

Please share your opinions.
        Thanks and bye,
        Milan

[1] https://bugzilla.gnome.org/show_bug.cgi?id=694322