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

[Matthew Barnes <mbarnes redhat com>]

On Thu, 2013-03-21 at 12:41 +0100, Milan Crha wrote:
> 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.

It's not really the client or even the client connection which owns the
mode, but rather the backend.  The backend can only operate in one mode
at a time, since it authenticates or sets up a secure TCP connection on
behalf of _all_ clients.

I'd suggest a scheme were the client connection can provide the backend
with some sort of token which gives the backend permission to interact
with the user for as long as that connection is open.

When I was working on Ubuntu Online Accounts I learned their signond
system used an enum they called UiPolicy which I found appealing.

https://code.google.com/p/accounts-sso/source/browse/lib/SignOn/sessiondata.h?repo=signond&name=2.4#58

If we rank a similar set of UI policies according to a desired
precedence, perhaps like:

    NO_USER_INTERACTION_POLICY   (lowest precedence)
    ALLOW_NOTIFICATIONS_POLICY
    ALLOW_MODAL_DIALOGS_POLICY   (highest precedence)

then the backend could act according to the token with the highest
precedence.

(ALLOW_NOTIFICATIONS_POLICY could simply submit a "hey, this needs your
attention!" desktop notification in lieu of a dialog, perhaps with an
action button that would allow further user interaction.)

So for example, if a client submits an ALLOW_NOTIFICATIONS_POLICY token
to a backend that only previously had NO_USER_INTERACTION_POLICY tokens,
then the backend may now submit a desktop notification if it fails to
authenticate or establish a secure TCP connection.

If another client comes along and submits an ALLOW_MODEL_DIALOGS_POLICY
token to that same backend, the backend would then be allowed to act as
it does currently, for as long as it has that token.

Does that make sense?

Submitting these tokens could be a new EClient method, so we don't have
to hack the existing API.  Then it's just a matter of tracking tokens on
the server-side, which I'm sure is not too difficult.

Matt