Subject: private stuff "temporary" exposed

From: Alan Griffiths <[email-masked]>
Date: Fri, 03 Oct 2014 12:23:40 +0100

Some time ago we introduce a "temporary" facility to hook into the
protobuf messaging protocol. This is exemplified by the
DemoPrivateProtobuf acceptance tests. This support was intended to allow
faster prototyping of some features that would eventually migrate into Mir.

Once these features were stable and integrated into Mir we intended to
remove this support (and these files have always carried a warning not
to use these APIs "for real").

As part of our stabilization of API and ABI efforts we should be trying
to remove this support from the API. In particular, Mir cannot ensure
compatibility across different Mir servers for any toolkits that depend
on such features.

However, things have not worked out as intended. These APIs are in use
for an (apparently stable) unity.protobuf.UnityService service copied
between platform-api, unity-mir and qtmir.

It would clearly be better to have a single definition of this service
in Mir than requiring all downstream projects to replicate it for
compatibility.

Thoughts?

---

From: Alexandros Frantzis <[email-masked]>
Date: Fri, 3 Oct 2014 15:28:00 +0300

> between platform-api, unity-mir and qtmir.

My understanding is that Unity is now using DBus for clipboard
support. QtMir doesn't use protobuf any more, and the unity-mir project
is obsolete. There are still references to unity.protobuf.UnityService
in platform-api, but I don't think the code path is actually useful.

If the above is correct, then no one is using our temporary protobuf
facility any more. Unless we think that it may still be useful as a
prototyping facility, we can remove it.

> in Mir than requiring all downstream projects to replicate it for

As discussed above, this may be a non-issue, but, in case we do need to
keep the service, I don't think we should involve Mir. Currently, the
UnityService API is specific to the Unity shell and Mir shouldn't have
any knowledge of shell specific constructs. If we think the
functionality is useful in general we should promote it to a proper Mir
API.

Thanks,
Alexandros

---

From: Alan Griffiths <[email-masked]>
Date: Fri, 03 Oct 2014 14:13:09 +0100

> prototyping facility, we can remove it.

I think you're right.

I guess my first step is to zap the platform-api code...

---

From: Alan Griffiths <[email-masked]>
Date: Fri, 03 Oct 2014 15:05:41 +0100

> I guess my first step is to zap the platform-api code...

Giving up for now.

Zapping the code is easy.

Understanding the surrounding code enough to be sure of not breaking
things though...