the book/calendar backends are currently designed to not have any direct
UI interaction with user, they basically serve for data only. While it
works, it has its caveats, like when user tries to access server using
SSL with self-signed certificate. This should be done like in Camel,
where user is asked what to do, instead of, currently implemented,
checkbox in account preferences for "Ignore invalid certificates".
Another usecase for direct UI interaction is, as xtian suggested some
time ago, when synchronizing offline data to the server, with discovered
conflicts. There might be found more usecases for sure.

What I have on mind is something what Camel already provides [1], the
camel_session_alert_user() function, which basically provides generic
dialog facility for asking users. The question is where to put such
functionality for book/calendar backends, because they are
client-oriented, not session oriented like providers in Camel. It would
not work to teach each client, and also user of the client, about this
interaction, thus I think the right place is evolution-source-registry,
which already requires gtk. This can be hidden on the backend side by
some base class function e_backend_alert_user(), and where it'll pass
the data is up to it. Note this is not used for random errors, for that
is other e_cal/book_backend_notify_error() function, which will be left.

One related thing, as I mentioned the server certificates and their
trust, this should be managed by one central point too - xtian already
reads the binary file from multiple processes, which is not optimal -
thus I would move the SSL certificate trust database management to the
evolution-source-registry as well. Same as it requires place where one
can check the SSL database, and possibly take back his/her previous
reject/accept, but there is none in evolution at the moment, as far as I

What would people think about these two things?


evolution-hackers mailing list
To change your list options or unsubscribe, visit ...

Reply via email to