Mojom Naming Bikeshed Summer 2015 Edition

[Ben Goodger (Google)]

(Sending thru mojo-dev, since this got to be pretty off-topic in the bug & I think this deserves broader visibility. The drought here in California has caused the interface naming bikeshed to take a bit of a beating this year so maybe it's time to paint it again.)

Scott V. has made a similar argument about the canonical-ness of any particular client library.

With that said I'm also in favor of some sort of decoration of the interfaces. I* certainly has some degree of industry acceptance but where it falls down is other generated types like structs, enums etc. This is where a namespace is better. In an earlier time there was an argument made against namespaces because there was some hope that mojom structs could model idiomatic C structs and be used above this layer in code. I think thus far our implementation of struct bindings have fallen short in this regard so this objection should no longer be an issue. There was also a (IMO weaker) argument about the namespace being redundant for interfaces for which there is no client lib. I forget what the other issues were other than general crankiness about more decorations.

I would consider using something descriptive like "mojom" as the namespace as the generated code is but one contract/interface in a layercake of such things.

A related question - should the various InterfacePtr typedefs go into such a nested namespace or not?

-Ben

Jeff Brown wrote:

I've been thinking of the C++ Mojo bindings as the foundation of one
particular C++ based framework rather than as a canonical client
implementation. There's nothing all that special about these bindings
other than the fact that we think they are generally useful. Someone else
could quite reasonably build completely different bindings of their own.
Given the importance of IPC in Mojo, it seems reasonably clear that
applications will need to be able to communicate directly over Mojo
interfaces, even though they will likely rely on their framework to provide
an easier foundation to work with (wrappers, base classes, APIs).
So that means we're likely to see this name collision crop up fairly often
because we'll often have two different representations of a given concept
coexisting. eg. Application (mojom contract type) vs ApplicationImpl
(framework type).
I might recommend one of the following approaches:
1. Push mojom generated types into their own namespace, separate from other
framework types. eg. mojo::contracts vs mojo.
2. Deemphasize mojom generated types by applying a prefix or suffix. eg.
IApplication or ApplicationInterface. (ick)
In general, I would prefer using a "contracts" (or "interfaces") namespace
since it will help with API hygiene and prevent implementation details of
generated code from leaking into the primary API surface of the framework.
An app can always use contract types directly but developers should
generally be shown the framework types first.
Jeff.

On Mon, Aug 10, 2015 at 7:54 PM Ben Goodger <notifi...@github.com>
wrote:

> I agree with that general sentiment, I think the hangup here has come from
> there being a corresponding mojom interface Application which collides.
>
> The debates we've had have covered the following points:
> - which is the canonical interface? the mojom interface or the C++ client
> lib?
> - in the case of the application library & the view manager it's the client
> lib. for other services, it can just be the mojom.
> - for cases where the canonical interface is the client lib, the target of
> the mojom interface is language binding developers.
> - we discussed pushing mojom interfaces into nested interfaces, but since
> there wasn't a single rule we felt bad about doing that.
>
> Perhaps in the cases where we intend mojom to be an implementation we
> should use the module feature of mojom to namespace the interface, e.g.
> module mojo.internal for application.mojom.
>
> -Ben
>
> On Mon, Aug 10, 2015 at 3:45 PM, Jeff Brown <notifi...@github.com>
> wrote:
>
> > Incidentally, I'd recommend removing the "Impl" suffix from any classes
> > which are intended to be part of the Mojo library APIs.
> >
> > Rationale: Impl usually denotes an internal implementation type so having
> > Impl in the name makes it look like the application is doing something
> > wrong (violating encapsulation).
> >
> > In general, we might seek simpler names such as Application.
> >
> > Jeff.
> >
> > On Mon, Aug 10, 2015 at 1:17 PM James Robinson <notifi...@github.com
> >
> > wrote:
> >
> > > returning scoped_ptr is OK if you're OK taking a dependency on //base
> (or
> > > C++11 stdlib) in ConnectToApplication. We aren't depending on either in
> > the
> > > mojo SDK currently. We'd like to depend on C++11 stdlib, but Chrome on
> > Mac
> > > is holding that back.
> > >
> > > —

> > > Reply to this email directly or view it on GitHub
> > > <https://github.com/domokit/mojo/issues/367#issuecomment-129593135>.
> >
> > >
> >
> > —
> > Reply to this email directly or view it on GitHub
> > <https://github.com/domokit/mojo/issues/367#issuecomment-129636837>.
> >
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/domokit/mojo/issues/367#issuecomment-129686283>.

[Ben Goodger (Google)]

Trung wrote:

 

My two cents: 1. The interface is generally the most important thing, it's undesirable to
clutter names of interfaces with additional verbiage. E.g., if |Foo| is a
mojom interface, the thing that people will deal with the most are
|FooPtr|s (or even |Foo*|s) and |FooRequest|s.

Why? That's not the case for Application & the View Manager or the GL stuff.

It seems completely conceivable that for complex services there are language-specific client libs that are widely used to make speaking to the underlying service easier.

-Ben

[James Robinson]

On Tue, Aug 11, 2015 at 2:48 PM, Ben Goodger (Google) <b...@chromium.org> wrote:

Trung wrote:

 

My two cents: 1. The interface is generally the most important thing, it's undesirable to
clutter names of interfaces with additional verbiage. E.g., if |Foo| is a
mojom interface, the thing that people will deal with the most are
|FooPtr|s (or even |Foo*|s) and |FooRequest|s.

Why? That's not the case for Application & the View Manager or the GL stuff.

Application can be dealt with at the mojom layer and is in every language except C++ without using the C++ libraries.  GL is different as we don't expose a GL mojom interface, we expose a set of C entry points.  I'd argue the view manager having a think C++ client library is a bug that makes that system unnecessarily hard to use, not a pattern to follow.

I'm sure we (and many other people) will provide libraries and toolkits that wrap mojom interfaces to do different things but the mojom defines the interface that is exposed to developers.

- James

[Viet-Trung Luu]

On Tue, Aug 11, 2015 at 2:48 PM, Ben Goodger (Google) <b...@chromium.org> wrote:

Trung wrote:

 

My two cents: 1. The interface is generally the most important thing, it's undesirable to
clutter names of interfaces with additional verbiage. E.g., if |Foo| is a
mojom interface, the thing that people will deal with the most are
|FooPtr|s (or even |Foo*|s) and |FooRequest|s.

Why? That's not the case for Application & the View Manager or the GL stuff.

• Application is odd because it's something that the shell talks to, not other apps.
• People (here in mojo land) are unhappy with the ViewManager, because it's (perceived) as being too hard to use, especially from other languages.
• GL is special, since we don't want to provide stable mojom interfaces but instead have the system provide C entrypoints. (This is mainly so we don't have a stable interface to command buffers. E.g., in the future, we might be able to make Vulkan the first class thing, and just provide GL on top of Vulkan.)

I think language-specific helpers are useful to make things more convenient/less verbose, but I think that it's a design failure if it's actually hard (as opposed to merely tedious) to use an interface without a client library.

To unsubscribe from this group and stop receiving emails from it, send an email to mojo-dev+u...@chromium.org.

[Ben Goodger (Google)]

On Tue, Aug 11, 2015 at 2:55 PM, Viet-Trung Luu <viettr...@chromium.org> wrote:

• Application is odd because it's something that the shell talks to, not other apps.

Does that make it odd? Isn't the shell just another app?

• People (here in mojo land) are unhappy with the ViewManager, because it's (perceived) as being too hard to use, especially from other languages.

I'm curious to learn more. I'm quite willing to believe the current implementation is imperfect. I know there are some simplifications that could be achieved by flattening some of the UI services in mojo-land. We've already begun to do this downstream in the Mandoline forks. But that's service side consolidation, unrelated to the client-lib.

• GL is special, since we don't want to provide stable mojom interfaces but instead have the system provide C entrypoints. (This is mainly so we don't have a stable interface to command buffers. E.g., in the future, we might be able to make Vulkan the first class thing, and just provide GL on top of Vulkan.)

I think language-specific helpers are useful to make things more convenient/less verbose, but I think that it's a design failure if it's actually hard (as opposed to merely tedious) to use an interface without a client library.

This is a fine ideal but I'm concerned it has the ability to gloss over some inherent complexity in specific system services.

-Ben

[Adam Barth]

On Tue, Aug 11, 2015 at 3:04 PM Ben Goodger (Google) <b...@chromium.org> wrote:

On Tue, Aug 11, 2015 at 2:55 PM, Viet-Trung Luu <viettr...@chromium.org> wrote:

• Application is odd because it's something that the shell talks to, not other apps.

Does that make it odd? Isn't the shell just another app?

The shell is the one thing in the system that isn't an app.  :)

• People (here in mojo land) are unhappy with the ViewManager, because it's (perceived) as being too hard to use, especially from other languages.

I'm curious to learn more. I'm quite willing to believe the current implementation is imperfect. I know there are some simplifications that could be achieved by flattening some of the UI services in mojo-land. We've already begun to do this downstream in the Mandoline forks. But that's service side consolidation, unrelated to the client-lib.

The client lib makes it difficult to interact with the view_manager from other languages.  That makes it difficult to embed child views in Sky apps, for example, because they're written in Dart.  We could write client libraries for all the various languages we support, but it seems better to redesign how apps visually embed each other in order to remove the need for a client library at all.

Adam

[Ben Goodger (Google)]

On Tue, Aug 11, 2015 at 3:52 PM, Adam Barth <aba...@chromium.org> wrote:

On Tue, Aug 11, 2015 at 3:04 PM Ben Goodger (Google) <b...@chromium.org> wrote:

On Tue, Aug 11, 2015 at 2:55 PM, Viet-Trung Luu <viettr...@chromium.org> wrote:

• Application is odd because it's something that the shell talks to, not other apps.

Does that make it odd? Isn't the shell just another app?

The shell is the one thing in the system that isn't an app.  :)

In practice it isn't, but are the connections between it and applications any different than those between applications?

• People (here in mojo land) are unhappy with the ViewManager, because it's (perceived) as being too hard to use, especially from other languages.

I'm curious to learn more. I'm quite willing to believe the current implementation is imperfect. I know there are some simplifications that could be achieved by flattening some of the UI services in mojo-land. We've already begun to do this downstream in the Mandoline forks. But that's service side consolidation, unrelated to the client-lib.

The client lib makes it difficult to interact with the view_manager from other languages.  That makes it difficult to embed child views in Sky apps, for example, because they're written in Dart.  We could write client libraries for all the various languages we support, but it seems better to redesign how apps visually embed each other in order to remove the need for a client library at all.

Do you have a particular design in mind?

The View Manager was designed so that there would be a single FIFO between the view manager and an embedded application so that there could be some guarantee around ordering of messages. This led to a monolithic interface quite different to the type of API typical in UI frameworks. It's certainly possible to program against ViewManagerService directly, you just end up having to carry around some view specific state/bookkeeping to make it manageable. The client lib emerged to unify some of this.

-Ben

[Adam Barth]

On Tue, Aug 11, 2015 at 4:11 PM Ben Goodger (Google) <b...@chromium.org> wrote:

On Tue, Aug 11, 2015 at 3:52 PM, Adam Barth <aba...@chromium.org> wrote:

On Tue, Aug 11, 2015 at 3:04 PM Ben Goodger (Google) <b...@chromium.org> wrote:

On Tue, Aug 11, 2015 at 2:55 PM, Viet-Trung Luu <viettr...@chromium.org> wrote:

• Application is odd because it's something that the shell talks to, not other apps.

Does that make it odd? Isn't the shell just another app?

The shell is the one thing in the system that isn't an app.  :)

In practice it isn't, but are the connections between it and applications any different than those between applications?

Dunno.  I was just answering your question. 

• People (here in mojo land) are unhappy with the ViewManager, because it's (perceived) as being too hard to use, especially from other languages.

I'm curious to learn more. I'm quite willing to believe the current implementation is imperfect. I know there are some simplifications that could be achieved by flattening some of the UI services in mojo-land. We've already begun to do this downstream in the Mandoline forks. But that's service side consolidation, unrelated to the client-lib.

The client lib makes it difficult to interact with the view_manager from other languages.  That makes it difficult to embed child views in Sky apps, for example, because they're written in Dart.  We could write client libraries for all the various languages we support, but it seems better to redesign how apps visually embed each other in order to remove the need for a client library at all.

Do you have a particular design in mind?

Some folks were going to experiment with different approaches.  One approach that I'd like to try is to remove notions of position and extent from the view manager and just have view manager understand hierarchy.  The position and extent of child views would be handled via Surfaces, which might also then be involved in hit testing.  That would also solve the problem that the view manager doesn't understand rotations and other matrix transformations.

The View Manager was designed so that there would be a single FIFO between the view manager and an embedded application so that there could be some guarantee around ordering of messages. This led to a monolithic interface quite different to the type of API typical in UI frameworks. It's certainly possible to program against ViewManagerService directly, you just end up having to carry around some view specific state/bookkeeping to make it manageable. The client lib emerged to unify some of this.

The reality is that the view manager is basically abandoned code.  The folks who worked on it left the project to work on other things.  In the intervening time, we've iterated on other parts of the system to align them with our goals.  It's possible that if we had someone that was enthusiastic about the current view manager design that they could iterate on it to make it do what we want it to do, but instead the current plan is to get a new set of people interested in composability and to have them design and build something (potentially new) that does what we need.

Adam

[Ben Goodger (Google)]

On Tue, Aug 11, 2015 at 4:27 PM, Adam Barth <aba...@chromium.org> wrote:

The client lib makes it difficult to interact with the view_manager from other languages.  That makes it difficult to embed child views in Sky apps, for example, because they're written in Dart.  We could write client libraries for all the various languages we support, but it seems better to redesign how apps visually embed each other in order to remove the need for a client library at all.

Do you have a particular design in mind?

Some folks were going to experiment with different approaches.  One approach that I'd like to try is to remove notions of position and extent from the view manager and just have view manager understand hierarchy.  The position and extent of child views would be handled via Surfaces, which might also then be involved in hit testing.  That would also solve the problem that the view manager doesn't understand rotations and other matrix transformations.

Yep. This redundancy bugs me in Chrome's assorted UI frameworks as well. I think Fady plans to make a change like this in our downstream fork once he gets further along. We've made some other simplifications already, like eliminating the window manager and changing the embed handshake so that the embedder performs the connection (and maintains the relationship with) the embeddee. All of this is orthogonal to the client lib however.

 

The View Manager was designed so that there would be a single FIFO between the view manager and an embedded application so that there could be some guarantee around ordering of messages. This led to a monolithic interface quite different to the type of API typical in UI frameworks. It's certainly possible to program against ViewManagerService directly, you just end up having to carry around some view specific state/bookkeeping to make it manageable. The client lib emerged to unify some of this.

The reality is that the view manager is basically abandoned code.  The folks who worked on it left the project to work on other things.  In the intervening time, we've iterated on other parts of the system to align them with our goals.  It's possible that if we had someone that was enthusiastic about the current view manager design that they could iterate on it to make it do what we want it to do, but instead the current plan is to get a new set of people interested in composability and to have them design and build something (potentially new) that does what we need.

Makes sense.

-Ben