On Thu, Dec 12, 2013 at 11:02 AM, Alan Griffiths <alan.griffi...@canonical.com> wrote: > On 12/12/13 09:34, Thomas Voß wrote: >> I don't see why we need a way to extend the protocol. We own every >> part of the stack, top to bottom, and I don't see why the shell would >> need a way to communicate to clients that is opaque to Mir. If it's an >> issue of unaligned development pace, we should rather fix the process >> as opposed to decoupling Mir from what Unity8 needs. > > The question I'm trying to resolve in this thread is how much support > for standardising protocols it is appropriate for Mir to provide. > > What we've seen over the past months is that unity8 has a lot of > communication with the toolkits that do not represent anything that > matters directly to Mir (or to USC). The past practice of providing an > implementation of these messages has proven problematic: every time > Unity8 needs a new message passing we get changes in the Mir client API > that are not driven by Mir, just by the need to pass these messages. >
Fair, but *some* client API has to change, why not Mir's then? As long as we are conscious of the changes and bump version appropriately, we are good. Coming up with an extension mechanism is an escape from a strict and very helpful versioning scheme from my perspective and I do not agree that we need a generic extension mechanism at this point. > There is general agreement that a generic method for passing messages > through Mir is needed, The "poster child" from last week's meetings > being cut-and-paste. > > Mir doesn't need to be involved in cut-and-paste beyond passing messages > - any intelligence lies in the communication between shell and toolkit. > While there are good reasons to standardise a cut-and-paste protocol the > Mir project isn't the place to do this. This protocol can develop and > change without changes to the Mir APIs. > Agreed, but the real place to do this is not the shell but the content hub (as discussed later on with Gerry and Ricmm). So taking this example as a driving use-case might skew the conversation. Thomas > > -- > Mir-devel mailing list > Mir-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/mir-devel -- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
