On Fri, Nov 25, 2016 at 9:03 PM, Alan Griffiths <alan.griffiths@canonical.com> wrote:<br>
<blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">It could be that I'm confused, or it could be that we're confused. So
I'm starting with a quick email. If need be I'll create a doc for
discussion.

The current situation is that we have multiple incompatible
representations of the display configuration:

1. MirDisplayConfiguration and the mir_display_config_... functions.

2. MirDisplayConfig and the mir_display_configuration_... functions.

3. The mir::graphics::DisplayConfiguration interface and the various
platform implementations.

It looks as though we have started to replace 1 with 2 but haven't yet
finished.

Looking at the code it seems the various platform implementations of 3
"just" populate similar data structures to provide the same functionality.

I think there is enough commonality that a single internal
implementation based on 2 could be used across server, platforms and
clients. I'd go so far as to say that DisplayConfiguration is a concept
that ought to be in libmircore (with a suitably ABI-stable API).</div></blockquote><blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">

There would be advantages to having a single representation (DRY) and,
as servers, platforms and clients can operate in the same process, it is
easier to use,</div></blockquote><br><div>I'm ambivalent about this. Since the client-side implementation is just backed by the Protobuf-generated structures it's been *really* convenient to implement the various extra pieces of data we've needed.</div><div><br></div><div>I think it would be nice if we went the other way - move the *server* (at least the internal bits) away from an abstract ´DisplayConfigurationĄ and use the concrete RPC type there.</div><div><br></div><div>This is obviously unacceptable for any component of Mir that 3rd party code needs to interact with - graphics platforms, the shell, and so on.</div><div><br></div><div>Hm. I guess what I'm saying is that I think it'd be good to have a ABI-stable *adapter* in libmircore for all the interfaces-with-outside-code uses that backs onto a concrete RPC type. I'm not ambivalent about that :).</div>