Re: [Evolution-hackers] Move authentication of backends back to the client (3.13.90)

[Patrick Ohly <patrick ohly gmx de>]

On Mon, 2015-02-02 at 17:25 +0100, Milan Crha wrote:
>         Hello,
> I just committed a change, for 3.13.90 development version, into 
> evolution-data-server [1], evolution [2], evolution-ews [3] and 
> evolution-mapi [4], which moves authentication back to the clients.

As discussed with Milan on IRC, I was worried that this change would
break compatibility with SyncEvolution although SyncEvolution primarily
(exclusively?!) is used with local storage, which works without
authentication.

I now looked further and found that SyncEvolution already works with the
new EDS, despite the changed API (e_book_client_connect,
e_cal_client_connect). That's because SyncEvolution opens an ESource
with e_client_open(), which hasn't changed.

SyncEvolution obviously won't work for sources which require
authentication, but I don't think that'll be a big issue.

[...]

I have not looked at the concept in detail, but it looks reasonable at
first glance.

> The other follow-up work will be to adapt any "clients" and libraries 
> which might be affected by this change. I'd like to help as much as 
> I'll be able, thus if there will be any issues spotted, feel free to 
> ping me or drop me an email and I'll help you to migrate your code. I 
> also removed all the old authentication code and functions, to avoid 
> those system-modal prompts and basically all the old behavior users 
> didn't like, the same as to cleanup API as much as possible.
>         Bye,
>         Milan
>
> [1] https://git.gnome.org/browse/evolution-data-server/commit/?id=884fb8d872787d9

One comment that I already made on IRC: adding one additional int
parameter to e_book_client_connect and e_cal_client_connect falls a bit
short IMHO. I bet there will be some point in the future when some other
new parameter will also be needed, causing another API break which could
be avoided now.

What I would prefer instead of the additional int parameter is a
string->variant hash with a list of keys which can be extended in the
future without breaking the API. Old clients not passing enough
information then can either use reasonable defaults (when possible) or
get an error telling the user to get his software updated.

I think that's better than causing old software unconditionally to not
compile (due to a API change) or to not run (due to an ABI/soname
change), because it keeps the option open to run some old software
unchanged.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.