Thoughts on the limits of public headers

Alexandros Frantzis alexandros.frantzis at canonical.com
Mon Sep 29 16:25:58 UTC 2014


Hi all,

we recently hid a lot of our public headers, to avoid frequent ABI
breaks.  As we start to gradually re-expose useful headers I think it
will be good to have broad guidelines about the limits of what we
expose.

One point I feel needs further discussion is the level (if any) at which
we stop re-exposing abstractions that are needed only by the default
implementations of higher abstractions.

For example, we have the mc::Compositor class, the default
implementation of which uses a mc::DisplayBufferCompositor(Factory), the
default implementation of which uses a mc::Renderer(Factory). Each level
we expose adds flexibility to the framework, but also increases our
public API/ABI. Furthermore, the further down we move in the abstraction
layers, the more potential for instability the API/ABI has, since it's
affected more by surrounding implementation decisions (which tend to be
more unstable) instead of higher level architectural decisions (which
tend to be more stable).

The level of exposure should be evaluated on a case by case basis, but
here are some aspects that I think the answer depends on:

1. Whether the exposed abstractions represent core concepts

2. How much we want to encourage reuse of a particular default
   implementation, by exposing the interfaces of its re-implementable
   dependencies

3. Related to (2): How much easier this makes the lives of developers
   trying to use the Mir framework

Thoughts?

Thanks,
Alexandros



More information about the Mir-devel mailing list