Proposal: how to make incompatible changes

[Brad Bishop]

at 10:56 AM, Patrick Williams <patrick at stwcx.xyz> wrote:

> On Thu, Apr 23, 2020 at 12:20:53PM -0400, Brad Bishop wrote:
>> at 8:11 AM, Alexander Amelkin <a.amelkin at yadro.com> wrote:
>>
>>> Internally, for inter-process dbus communication the interface version
>>> could be checked during compile time to prevent problems that couldn't be
>>> detected by compiler/linker automatically.
>>
>> I like the idea of a stable, versioned DBus API.  Does anyone else?
>>
>> In the past there was opposition to that.  I’m not sure if there still is.
>
> Since we're deprecating the REST-dbus path and moving towards Redfish is
> there much advantage to a versioned DBus API?

It helps lower the barrier to comprehension and entry.  Unversioned &  
unstable IPC APIs are not normal and probably shocking to anyone that comes  
across them.

An unstable, unversioned API encourages bad behavior - e.g. I can just make  
this in-compatible change to the API and fix all the applications at the  
same time.  lock-step dependencies between 3 different projects  
(phosphor-dbus-interfaces, the client, and the server) is not a good thing.

Put another way - with an unstable and unversioned API - what is the point  
of having all these different projects and repositories?  It just becomes  
one giant monolithic code base.  If that is what we want, then we should  
structure it that way.  Nothing inherently wrong with that, but it seems  
like it would restrict how the code can be used.  Does that bother us?

> Alexander mentioned
> compile-time checking of the interface, but we already have that through
> sdbusplus.  The issues are:
>     1. Client bindings are not currently being generated.
>     2. Not every implementation is using them.
>     3. We don't have a good mechanism to deal with cross-repository
>        interface changes.
>
> I don't think a versioned DBus API solves any of these, except maybe #3

That's just it - these are the solution to the problems that an unstable  
and unversioned API bring, not the other way around.  It is all work one  
way or the other - we can do something atypical like have an unversioned  
and unstable API, and then write a bunch of frameworks and tooling around  
that so that it can work.  Or we can put in the effort to have a stable and  
versioned DBus API.  I would rather do the latter because that is how  
people have been using dbus effectively for a really long time.

> but that is only if we're going to write servers that support N-versions
> of the interfaces.
>
> It seems to me like a better investment is #1 and #2?

To be clear on #2, use of frameworks is an optional thing.  To get  
universal adoption of a framework, you have to first get universal  
acceptance of the merits of the framework.  So I suggest interlocking with  
the specific application maintainers before working on #2 to avoid wasting  
time.

> I'd personally
> like to have #1 implemented by the end of Sept at the latest.

Nice!

> Solving
> #3, I think, requires us to do some CI investment to support Gerrit
> topic-based testing.

Or we can avoid entirely, with a stable, versioned API :-)