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



On Wed, 2015-02-18 at 13:54 +0100, Patrick Ohly wrote:
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.

        Hi,
I would not do that this way. It would be horrible to call the 
function and create extra arguments for it in some sort of array and 
variants and so on. It's a pita to convert parameters forth and back 
when passing them through GDBus already, thus rather not add the same 
burden to the client functions too.

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.

I always understood that it's the soname version which is meant to 
cover these situations. Not that the two versions of eds can be 
installed in parallel in one prefix.

As I said on IRC, the API change was intentional, as a little heads-up 
for the change of the authentication, because the 
e_cal/book_client_connect() works differently now. I know it's 
inconvenient and so on, but it's every API change in any project.

        Bye,
        Milan



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]