Add an ApplicationConnector interface, etc.

Add an ApplicationConnector interface, etc.

Also do a bit of (minimal) cleanup of ApplicationImpl.

From the Shell interface, you can mint ApplicationConnectors, which
allows you to connect to other applications. This is useful if you want
to connect to applications from other threads or other environments
(e.g., inside a VM).

TODO(vtl): Maybe add a Duplicate() to ApplicationConnector. The reason
we don't just add a Duplicate() to Shell is that Shell is associated
with low-level stuff (e.g., process lifetime), and we may want to add
more low-level process-y stuff (which shouldn't be delegated) to it in
the future.

R=jamesr@chromium.org

Committed: https://chromium.googlesource.com/external/mojo/+/199850d6d0c03765ac121ba773057e1cc7eec1ec

[abarth-chromium, 2015-11-12 20:53:48]

abarth@chromium.org changed reviewers:
+ abarth@chromium.org

[abarth-chromium, 2015-11-12 20:53:48]

https://codereview.chromium.org/1435153003/diff/1/mojo/public/interfaces/appl...
File mojo/public/interfaces/application/BUILD.gn (right):

https://codereview.chromium.org/1435153003/diff/1/mojo/public/interfaces/appl...
mojo/public/interfaces/application/BUILD.gn:11: "application_connector.mojom",
I think you forgot to git add this one.  :)

[viettrungluu, 2015-11-12 21:03:55]

On 2015/11/12 20:53:48, abarth-chromium wrote:
>
https://codereview.chromium.org/1435153003/diff/1/mojo/public/interfaces/appl...
> File mojo/public/interfaces/application/BUILD.gn (right):
> 
>
https://codereview.chromium.org/1435153003/diff/1/mojo/public/interfaces/appl...
> mojo/public/interfaces/application/BUILD.gn:11: "application_connector.mojom",
> I think you forgot to git add this one.  :)

D'oh. Added/uploaded.

[viettrungluu, 2015-11-13 21:42:52]

Description was changed from

==========
Add an ApplicationConnector interface, etc.

WIP - missing tests, etc.
==========

to

==========
Add an ApplicationConnector interface, etc.

Also do a bit of (minimal) cleanup of ApplicationImpl.

R=jamesr@chromium.org
==========

[viettrungluu, 2015-11-13 21:42:52]

viettrungluu@chromium.org changed reviewers:
+ jamesr@chromium.org

[viettrungluu, 2015-11-13 21:45:19]

-> jamesr for review

[jamesr, 2015-11-13 21:51:20]

Pretty much every language has an application wrapper - what's the plan for
updating those?

https://codereview.chromium.org/1435153003/diff/120001/mojo/go/tests/applicat...
File mojo/go/tests/application_impl_test.go (right):

https://codereview.chromium.org/1435153003/diff/120001/mojo/go/tests/applicat...
mojo/go/tests/application_impl_test.go:125: // TODO(vtl)
file a bug?

[viettrungluu, 2015-11-13 22:04:08]

On 2015/11/13 21:51:20, jamesr wrote:
> Pretty much every language has an application wrapper - what's the plan for
> updating those?

That's a good question. I expect this will vary from language to language
(depending on the particular wrapper's level/type of insanity). So I filed a
bug: https://github.com/domokit/mojo/issues/534 .

> 
>
https://codereview.chromium.org/1435153003/diff/120001/mojo/go/tests/applicat...
> File mojo/go/tests/application_impl_test.go (right):
> 
>
https://codereview.chromium.org/1435153003/diff/120001/mojo/go/tests/applicat...
> mojo/go/tests/application_impl_test.go:125: // TODO(vtl)
> file a bug?

Done (https://github.com/domokit/mojo/issues/533).

[viettrungluu, 2015-11-16 20:54:15]

ping

[jamesr, 2015-11-16 22:01:05]

lgtm but please elaborate a bit in the commit message about why this is being
split out and what splitting it out allows

[abarth-chromium, 2015-11-16 22:09:35]

If I have an ApplicationConnector is there a way for me to get another one?

[jamesr, 2015-11-16 22:19:53]

On 2015/11/16 at 22:09:35, abarth wrote:
> If I have an ApplicationConnector is there a way for me to get another one?

No, the thing that owns the shell connection has to create ApplicationConnectors
and decide who gets them.  It's a fairly powerful capability since it lets you
create connections as if you were the app (i.e. impersonate the app as far as
the shell is concerned).

[jamesr, 2015-11-16 22:40:46]

(copying question from email into review so the thread isn't split)

Adam said:
> Support you have some C++ code that runs some code in side a VM (say Dart)
than then runs some > code inside in interpreter (say a JS interpreter running
inside the Dart VM).  If the Dart code > gets only an ApplicationConnector, how
then can it give the JS code an ApplicationConnectors
> all to its own?  If you're saying I need to hand the unique Shell handle from
C++ to Dart, then
> you haven't solved my problem because I still have this unique resource (the
shell handle)
> that I need to decide which language gets to bind.

With this patch the code that owns the Shell handle has to decide how many
ApplicationConnectors to mint and who to hand them off to.  You're right that
this does not allow minting new resources from an existing one.

I think the mismatch you're running into is that from the shell's perspective
the original handle is a unique resource that it uses to identify other things
in the system.  If you want another part of the system to be something that the
shell understands you need to provide a handle it understands.  In the case of
C++ embedding a Dart VM which embeds an interpreter one way to do this is to use
the content handle mechanism to have the shell understand the C++, Dart, and JS
pieces as separate entities that it can manage.  This is how Flutter works - the
shell connects to the Flutter C++ engine as one entity and then uses the content
handler to address the Dart code as another entity.  Each entity has its own
shell message pipe that it can use to create ApplicationConnectors as it wishes.
 If a flutter app (dart code) ran a JS interpreter, it could use the content
handler mechanism to create a shell identity for that JS code.  If it didn't,
then it would be responsible for handling the shell interface and creating
ApplicationConnectors for the JS code.

[viettrungluu, 2015-11-16 22:54:25]

On 2015/11/16 22:40:46, jamesr wrote:
> (copying question from email into review so the thread isn't split)
> 
> Adam said:
> > Support you have some C++ code that runs some code in side a VM (say Dart)
> than then runs some > code inside in interpreter (say a JS interpreter running
> inside the Dart VM).  If the Dart code > gets only an ApplicationConnector,
how
> then can it give the JS code an ApplicationConnectors
> > all to its own?  If you're saying I need to hand the unique Shell handle
from
> C++ to Dart, then
> > you haven't solved my problem because I still have this unique resource (the
> shell handle)
> > that I need to decide which language gets to bind.
> 
> With this patch the code that owns the Shell handle has to decide how many
> ApplicationConnectors to mint and who to hand them off to.  You're right that
> this does not allow minting new resources from an existing one.
> 
> I think the mismatch you're running into is that from the shell's perspective
> the original handle is a unique resource that it uses to identify other things
> in the system.  If you want another part of the system to be something that
the
> shell understands you need to provide a handle it understands.  In the case of
> C++ embedding a Dart VM which embeds an interpreter one way to do this is to
use
> the content handle mechanism to have the shell understand the C++, Dart, and
JS
> pieces as separate entities that it can manage.  This is how Flutter works -
the
> shell connects to the Flutter C++ engine as one entity and then uses the
content
> handler to address the Dart code as another entity.  Each entity has its own
> shell message pipe that it can use to create ApplicationConnectors as it
wishes.
>  If a flutter app (dart code) ran a JS interpreter, it could use the content
> handler mechanism to create a shell identity for that JS code.  If it didn't,
> then it would be responsible for handling the shell interface and creating
> ApplicationConnectors for the JS code.


I think that ApplicationConnector having a "Duplicate()" is entirely plausible
(and I can add that in a separate change).

If you're trusting some other code with one of your ApplicationConnectors, then
you may as well trust it with a "Duplicate()": that code presumably has the
ability to proxy uses of that ApplicationConnector or to hand it off to anyone
it likes, so not allowing "Duplicate()" doesn't help you security-wise.

The reason I don't want to just give Shell a "Duplicate()" is that it's special,
in the sense that it's tied to the lifetime of the "process" (and is the natural
place for other process-y things, which make sense only at a low level).

It's conceivable that you'd want to delegate some of these process-y things to
Dart code, etc., but in that case the C++ code would probably also want to do
stuff, at which point the C++ code really is proxying (or maybe not exposing
Shell directly, but something Shell-like).

[viettrungluu, 2015-11-16 23:19:21]

Description was changed from

==========
Add an ApplicationConnector interface, etc.

Also do a bit of (minimal) cleanup of ApplicationImpl.

R=jamesr@chromium.org
==========

to

==========
Add an ApplicationConnector interface, etc.

Also do a bit of (minimal) cleanup of ApplicationImpl.

From the Shell interface, you can mint ApplicationConnectors, which
allows you to connect to other applications. This is useful if you want
to connect to applications from other threads or other environments
(e.g., inside a VM).

TODO(vtl): Maybe add a Duplicate() to ApplicationConnector. The reason
we don't just add a Duplicate() to Shell is that Shell is associated
with low-level stuff (e.g., process lifetime), and we may want to add
more low-level process-y stuff (which shouldn't be delegated) to it in
the future.

R=jamesr@chromium.org
==========

[viettrungluu, 2015-11-16 23:21:03]

Committed patchset #7 (id:120001) manually as
199850d6d0c03765ac121ba773057e1cc7eec1ec (presubmit successful).