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

[Patrick Ohly <patrick ohly gmx de>]

On Thu, 2015-02-19 at 07:43 +0100, Milan Crha wrote:
> 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'm not convinced, but it's your project. However, I reserve the right
to say "told you so" once the API needs to be changed the next time.

> > 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.

But distro's typically don't do that because it's extra work to maintain
two versions of the same software in parallel. It also would not work
for EDS, because each client library is typically tightly coupled with a
certain daemon version, and those cannot be installed or run in
parallel.

-- 
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.