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 _______________________________________________ evolution-hackers mailing list [email protected] To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
