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

[Tristan Van Berkom <tristan upstairslabs com>]

I havent been active in EDS for some time so feel free to take my
comments with an appropriate grain of salt...

On Fri, 2015-02-27 at 11:09 +0100, Patrick Ohly wrote:
> 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.

Changing API is always a delicate dance, I have to agree that creating
a less convenient API in anticipation of future changes is not a
desirable way forward.

Hopefully most of these semantics need not be changed in terms of
'ways to open the client'[0]. It's also hard to imagine many
justifications for requiring more arguments to e_book_client_connect(),
we do have the ESourceExtensions and the backend properties which are
very flexible already.

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

This tight coupling between sonames and EDS daemon does not strictly
have to be the case, however I would like to echo Patrick's concerns
with a word of caution against incrementing the soname of the user
facing libraries.

It's one thing to bump the sonames of the backend related libraries
(libedata-book, libedata-cal and everything backend related), as all
this means is that any third party backend providers need to relink
against the new API and ensure everything works.

It's quite another thing to break the user facing libebook and libecal
API, as it means:

  o Any frontend users of EDS need to relink and ensure their EDS
    based applications still work

  o For applications which just work and opt out of the extra work
    involved in linking the new libebook/libecal, these would no
    longer benefit from bugfixes made in the new EDS API.

  o As an alternative to the previous, this may in fact add
    an extra maintenance burden, should bug fixes really need to
    be backported to previous versions with different sonames.

    I.e. telling someone to upgrade the EDS libraries on an older
    system is no longer valid on it's own, as applications are not
    linking the same soname yet.

Just saying, breaking API in the user facing libraries is not something
to take lightly, bumping the soname in these libraries should really
be a last resort.

Best Regards,
    -Tristan

[0]: A note on semantics of opening a client, we really should be
deprecating the DRA specific semantics in favor of making DRA the
default and just falling back on pure DBus in the case where DRA
is unavailable, this was the original plan, and would make for
one less 'technique' of opening the client, which is really just
API bloat at this point, anyway.