Thoughts on the limits of public headers

Kevin DuBois kevin.dubois at canonical.com
Mon Sep 29 21:26:11 UTC 2014


This is good to think about, because it'll help us sort out the headers and
make sure that core concepts of mir are available to our users. It'll also
let us refocus; that is, make sure that the interfaces we want the
downstreams to use match up with the needs of the downstreams.

I think the compositor ecosystem is an example of where we're exposing too
much stuff that a user of mir would reasonably feel comfortable writing
(and even want to rewrite). One thing in particular, I don't think we
should provide classes that do GL/EGL plumbing. A user who comes to the mir
project wanting to customize the graphics displayed will be a user who can
compile a shader. (there's more than just the compositor system, but its a
good example)

So I agree with the criteria. The problems that we promise to solve
(eg, input processing, display/multimonitor, buffer management, ipc
processing, platform implementations) should be more hidden. For the
problems the users are trying to solve (eg, where to put the window on the
display, how to organize the scene, the optimal spring constant on the
window wobble, etc) we shouldn't assume too much, and just have clear
interfaces that can be implemented and injected into the mir system.

Cheers,
Kevin

On Mon, Sep 29, 2014 at 12:25 PM, Alexandros Frantzis <
alexandros.frantzis at canonical.com> 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
>
> --
> Mir-devel mailing list
> Mir-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/mir-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20140929/1b6dae46/attachment.html>


More information about the Mir-devel mailing list