Thoughts on the limits of public headers

[Daniel van Vugt]

Noting that the hiding of headers in Mir 0.8, while causing some 
teething problems, has been very successful in reducing ABI bumps. 
Although we did bump ABIs in 0.8 it wasn't until late in the cycle that 
changes were committed needing any bumps. So that's a great improvement.

I do like the idea of hiding everything till someone requests it. Our 
previous approach of trying to predict which classes people should use 
turned out to be less successful than any of us expected. Admittedly 
there's a delay there in a user requesting a header and getting a 
release with it, but the benefits are certainly worth it.

On Kevin's points... We don't expose the GL plumbing classes right now. 
Their headers are in src/ AFAICS. Although I would like to have time to 
start doing more external shell development myself that would probably 
use them, that's not happening right now. So by the current rules they 
stay private/hidden/internal.


On 30/09/14 00:25, Alexandros Frantzis wrote:
> 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
>