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