Make Mozart view manager use the new compositor.

mojo/services/ui/views/interfaces/view_associates.mojom

Index: mojo/services/ui/views/interfaces/view_associates.mojom
diff --git a/mojo/services/ui/views/interfaces/view_associates.mojom b/mojo/services/ui/views/interfaces/view_associates.mojom
new file mode 100644
index 0000000000000000000000000000000000000000..6dec347f3a4685e2cae8da62d3df5e78f98bb010
--- /dev/null
+++ b/mojo/services/ui/views/interfaces/view_associates.mojom
@@ -0,0 +1,79 @@
+// Copyright 2015 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+[DartPackage="mojo_services"]
+module mojo.ui;
+
+import "mojo/public/interfaces/application/service_provider.mojom";
+import "mojo/services/ui/views/interfaces/views.mojom";
+import "mojo/services/ui/views/interfaces/view_trees.mojom";
+
+// View associates are trusted components that are attached to a view manager
+// instance with the purpose of offering additional services to views and
+// view trees registered beyond the basic operations performed by the
+// view manager itself.  Associates may be used to implement input,
+// accessibility, editing, and other capabilities.
+//
+// Associates are coupled to a view manager instance for the entire life
+// of that view manager.  Associates cannot be dynamically added or removed
+// since applications rely on the services that they offer and expect them
+// to be available for the lifetime of their views.  Moreover, all views and
+// view trees registered with a particular view manager instance share
+// the same set of associates.

[abarth, 2016/01/10 01:42:54]

That seems pretty limiting.

[jeffbrown, 2016/01/26 05:59:12]

Yes.  Deliberately so.  We'll see if this needs to change later.

+//
+// This mechanism is designed to avoid a potential explosion in complexity
+// if all features which depend on the state of views were implemented
+// in one place.
+//
+// TODO(jeffbrown): In the current implementation, the view manager binds
+// to a hard coded set of associates at start up time which can be overridden
+// from the command-line.  We should find a better way to register associates
+// once we decide how the system as a whole should be initialized.
+[ServiceName="mojo::ui::ViewAssociate"]
+interface ViewAssociate {
+  // Connects to the associate.
+  //
+  // The |inspector| provides a means for the view associate to query state
+  // from the view manager.
+  //
+  // The associate must return information about the services that it
+  // offers in |info|.
+  Connect(ViewInspector inspector) => (ViewAssociateInfo info);

[abarth, 2016/01/10 01:42:54]

It's interesting that you're doing initialization in this order.  My guess was
that you'd have the associates connect to the view manager and provide their
info.  It's hard to know what's better because we don't know the startup
sequence for the system.

[jeffbrown, 2016/01/26 05:59:12]

Launching all of the associate services upfront eliminates a lot of ambiguity so
it's a good starting point.  For example, this makes it so we don't have to
handle the case of an application asking for a service which might be provided
by an associate eventually but that hasn't started yet.  I'm not sure
application developers are prepared for a world where their input system might
come and go on them, for example.

The purpose here is to prevent the view system from becoming a giant monolithic
mess, not necessarily to allow for independent fail-over of each piece.

+
+  // Asks the associate to provide the view service identified by
+  // |interface_name| through the message |pipe| endpoint supplied by
+  // the caller.  If the host is not willing or able to provide the requested
+  // service, it should close the |pipe|.
+  //
+  // The |view_token| is the token of the view which requested the service.
+  ConnectToViewService(ViewToken view_token, string service_name,
+      handle<message_pipe> pipe);
+
+  // Asks the associate to provide the view tree service identified by
+  // |interface_name| through the message |pipe| endpoint supplied by
+  // the caller.  If the host is not willing or able to provide the requested
+  // service, it should close the |pipe|.
+  //
+  // The |view_tree_token| is the token of the view tree which requested
+  // the service.
+  ConnectToViewTreeService(ViewTreeToken view_tree_token,
+      string service_name, handle<message_pipe> pipe);
+};
+
+// Provides information about the services offered by an associate.
+struct ViewAssociateInfo {
+  // The names of view services offered by the associate.
+  // May be null if none.
+  array<string>? view_service_names;
+
+  // The names of view tree services offered by the associate.
+  // May be null if none.
+  array<string>? view_tree_service_names;
+};
+
+// Provides a view associate with the ability to inspect and perform operations
+// on the contents of views and view trees.
+interface ViewInspector {
+
+};