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
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
