# Running Mojo Applications

A Mojo application written in JavaScript is launched with mojo_shell like this:

```
  mojo_shell <js-application-url>
```

Where js-application-url is a URL understood by the shell. For example
a file or an http URL that names a JS source file. The JS file itself
must begin with a Mojo "shebang" that specifies the Mojo URL of the JS
content handler. In other words, the first line of the JS source file
must be:

```javascript
#!mojo mojo:js_content_handler
```

Following the shebang should be a single AMD module called "main" whose value
is an Application subclass. The JS content handler will create an instance of
the Application and make it the client of the Mojo shell. The JS content handler
is itself a Mojo application and it's responsible for creating an instance of V8
and loading the "main" JS module and all of the modules the main module
depends on. 

## JavaScript Classes

The JS content handler depends on the ECMAScript6 ("Harmony") classes feature.

As of January 2015 Chrome enables Harmony classes by default.


# The JS Application Class

Mojo JS applications are defined with the Application class. The
Application class handles incoming requests for services and provides
services of its own.

This is the overall structure of a JS Mojo application:

```javascript
#!mojo mojo:js_content_handler

define("main", ["mojo/services/public/js/application", 
  <list of other modules that this application depends on>
],
    function(application, <one parameter per dependent module>) {
      class MyApplication extends application.Application {
        constructor(appShell, url) {
          super(appShell, url); // Initializes this.shell, this.url.
          // MyApplication initializations here. 
        }

        initialize(args) {
        }

        acceptConnection(url, serviceProvider) {
        }
      }
    }

    return MyApplication;
  });
```

The hello.js example is little more than this basic skeleton.

The JS content handler loads the "main" module and constructs an
instance of its value, which must be an Application subclass. The
application's constructor is passed two arguments:

* `appShell` - a pointer to the Mojo shell. Typically this will be wrapped by a
    JS Shell object, see below.

* `url` - the URL this application was loaded from as a String.

The inherited Application class constructor initializes the shell and url
properties. It's unlikely that you'll want to use the appShell argument
directly.

The initialize() and acceptConnection() methods are defined by application.mojom
and they're needed because the JS content handler makes the JS application the
Mojo shell's client.

The intiailize() method is called once, after the constructor has run
and before any calls to acceptConnection(). The value of its parameter
is the argument list specified for this application with
mojo_shell. Arguments can be specified using the mojo_shell
`--args-for` command line argument or by just adding them after the
application's URL and enclosing the entire expression in quotes:

```
  mojo_shell '<js-application-url> arg1 arg2'
```
See the wget.js for an example of command-line argument use.

The acceptConnection() method is called each time another application connects
to this one. The first call corresponds the mojo_shell's initial connection.
The serviceProvider parameter is a JS ServiceProvider, see the "Requesting
and Providing Services" section below.

# JS Bindings

The JS bindings map from incoming Mojo messages to JS values, and
similarly from outgoing JS values to Mojo messages.

To use or implement a service you'll need the JS bindings for the
service's Mojo interface. The bindings are generated by the build system and end
up in files whose name is the same as the '.mojom' file with a '.js'
suffix. It's often helpful to look at the generated '.mojom.js' files.

The JS bindings for a Mojo interface's API are delivered as a JS module whose
name is based on the '.mojom' file's path. For example, to use the Mojo network
service you need the JS module based on network_service.mojom:

```javascript
  define("main", [
    "mojo/services/network/interfaces/network_service.mojom",
    "mojo/services/public/js/application",
  ]
    function(net, application) {
      class MyApplication extends application.Application {
        initialize(args) {
          var netService = this.shell.connectToService(
              "mojo:network_service", net.NetworkService);
          // Use netService's NetworkService methods.
        }
        ...
      }
      ...
    }
    return MyApplication;
  });
```

The first connectToService() parameter is the Mojo URL for the network service
application and the second is the JS "interface" object for NetworkService. The
JS interface object's properties identify the generated JS bindings classes
used to provide or connect to a service. For example (from
network_service.mojom.js):

```javascript
var NetworkService = {
  name: 'mojo::NetworkService', // Fully qualified Mojo interface name.
  proxyClass: NetworkServiceProxy,
  stubClass: NetworkServiceStub,
  // ...
};
```

The 'proxyClass' is used to access another application's NetworkService and the
'stubClass' is used to create an implementation of NetworkService. 

## JS Bindings for Basic Types

In most cases the mapping from Mojo types to JS types is simple. 

Mojo Type  | JS Type
------------- | -------------
bool  | true or false
int8, uint8  | Number
int16, uint16  | Number
int32, uint32  | Number
int64, uint64  | Number*
float, double  | Number
string  | String
array | Array
map | Map

The support for 64 bit integers is currently limited to 53 bits per
the current JS standard. Only integer values in the range from
``Number.MIN_SAFE_INTEGER`` to ``Number.MAX_SAFE_INTEGER`` can be
represented exactly. Larger and smaller values are approximated by
double precision Numbers.

Unspecified bool parameter or struct field values default to false
unless an explicit Mojo default was specified.

Unspecified integer values similarly default to 0.

Unspecified nullable string, array, and map values similarly default to
null and can be specified as null. In Mojom a nullable type has a
``?`` suffix.

## JS Bindings for Structs

Mojo structs are mapped to JS objects. An eponymous class is generated for each
struct type. The struct class constructor has an object-valued parameter to make
it a little easier to specify a struct value. For example:

```javascript
// Mojom definitions
struct Foo {
  string? name;
  array<int32>? values;
};

interface I {
  PassFoo(Foo foo);
}

// JavaScript Usage, assuming we have a proxy for I, iProxy

// Rough and ready struct construction:
var foo = new Foo;
foo.name = "foo";
foo.values = [1,2,3];
iProxy.PassFoo(foo);

// Using the Foo constructor parameter:
iProxy.PassFoo(new Foo({name: "foo", values: [1,2,3]}));
iProxy.PassFoo(new Foo); // name, values are null
iProxy.PassFoo(new Foo({name: null}); // Same as previous line.
```

An unspecified nullable struct parameter or struct field value defaults to 
null.


## JS Bindings for Interface Parameters

## Stubs and Proxies

TODO: briefly introduce message pipes. 
TODO: explain what stubs and proxies are, explain what's meant by "local" and "remote". 
TODO: explain the StubBindings and ProxyBindings functions.
TODO: support creating a proxy from a handle new MyProxy(someHandle);
TODO: explain the Connection object and how it relates to this stuff.

From a user's point of view, the bindings are in terms of the (remote)
proxy class and the (local) stub class. Properties are added to instances
of these classes using functions called StubBindings and ProxyBindings.

The caller and callee use cases that follow are  in terms of the following mojom:

```
interface I {
  provideFoo(Foo foo);  // TODO: Explain
  requestFoo(Foo& foo);  // TODO: Explain
} 
```

## Callers

Assuming that we have a proxy for interface I, iProxy.

An iProxy.provideFoo() call implies that we have an implementation of
Foo, and want a proxy for Bar (Foo's client).

```javascript
var barProxy;
iProxy.provideFoo(function(remote) {
  barProxy = remote;
  return myFooImpl;
});
```

An iProxy.requestFoo() call implies that we have an implementation of
Bar and want a proxy for Foo (Bar's client).

```javascript
var fooProxy;
iProxy.requestFoo(function(remote) {
  fooProxy = remote;
  return myBarImpl;
});
```

In the requestFoo() case, if no client were defined for Bar the function
parameter need not return anything.

The wget.js example includes a request for the URLLoader service.

## Callees

An implementation of provideFoo(Foo foo) implies that we have an
implementation of Bar (Foo's client) and want a proxy to the Foo
that has been passed to us.

```javascript
void provideFoo(fooProxy) {
  ProxyBindings(fooProxy).setLocalDelegate(myMyBarImpl);
}
```

An implementation of requestFoo(Foo& foo) implies that we have an
implementation of Foo and want a proxy for the Bar (Foo's client)
that's been passed to us.

```javascript
void requestFoo(barProxy) {
  ProxyBindings(barProxy).setLocallocalDelegate(myFooImpl);
}
```

## Mojo Responses are Promises

Mojo functions can return zero or more values called a "response". For example
the EchoString function below returns a string or null.

```javascript
interface EchoService {
  EchoString(string? value) => (string? value);
};
```

The response is delivered to the function caller asynchronously. In C++ the 
caller provides a Callback object whose Run() method has one argument for
each response parameter. In JS, Mojo functions that specify a response return
a Promise object. The Promise resolves to an object with one property per
response parameter. In the EchoString case that would be something like 
`{value: "foo"}`.

Similarly, the implementation of a Mojo interface functions that specify a
response, must return a Promise. The implementation of EchoString() could
be written like this:

```javascript
MyEchoStringImpl.prototype.EchoString = function(s) {
  return Promise.resolve({value: s});
};
```

# The JS Shell Class

The JS Shell class simplifies connecting to applications and services. It's a
wrapper for the Application's appShell argument. The Application constructor
creates a Shell and assigns it to `this.shell`.

The Shell's connectToService() method returns a "proxy" to a service provided by
another application.

```javascript
  define("main", [
    "mojo/services/network/interfaces/network_service.mojom",
    "mojo/services/public/js/application",
  ]
    function(net, application) {
      class MyApplication extends application.Application {
        initialize(args) {
          var netService = this.shell.connectToService(
              "mojo:network_service", net.NetworkService);
          // Use netService's NetworkService methods.
        }
        ...
      }
      ...
    }
    return MyApplication;
  });
```

In the netService case above the Shell connects to the Mojo application at
"mojo:network_service", then connects to its service called 
NetworkService.name with an instance of NetworkService.proxyClass. The proxy
instance is returned. The netService proxy can be used immediately.

The wget.js example demonstrates using the network service.

## Requesting and Providing Services

Mojo applications can connect to services provided by other applications and
they can provide services of their own. A service is an implementation of a Mojo
interface that was defined as part of a Mojo module in a ".mojom" file.

When an application starts, its initialize() method runs and then its
acceptConnection() method runs. The acceptConnection() method
indicates that another application has connected to this one and it
always runs at least once.

```javascript
acceptConnection(initiatorURL, serviceProvider) {
  // provide services to the initiator here
  // request services from the initiator here
}
```

The acceptConnection serviceProvider argument can be used to provide
services to the initiator, and to request services from the
initiator. An application can decide exactly what to do based on the
initiator's URL. The serviceProvider argument is-a JS ServiceProvider,
an object that wraps a Mojo ServiceProvider proxy. 

The ServiceProvider requestService() method gets a proxy for a service
from the initator and optionally provides a client implementation.

The ServiceProvider provideService() method registers an interface
implementation factory for a Mojo interface. The factory function is
provided with an proxy for the interface's client, if it has one.

An application can also connect to other applications and their
services using its shell's connectToApplication() and
connectToService() methods. The shell's connectToApplication() returns
a ServiceProvider. The shell's connectToService() method is just a
convenience, it's defined like this:

```javascript
connectToService(url, service, client) {
  return this.connectToApplication(url).requestService(service, clientImpl);
};
```

The value of service is an interface object that identifies a Mojo
interface that the application at url implements.

The usage examples that follow are based on the following trivial Mojo
interface:

```javascript
interface EchoService {
  EchoString(string? value) => (string? value);
};
```

### Requesting a Service Using the Application's Shell

The Shell's `connectToService()` method returns a proxy to a Mojo
service provided by another application. The proxy can be used immediately.

Given the URL of a Mojo application that implements the EchoService we
can use the application's shell to get an EchoService proxy. Here's a
complete application:

```javascript
#!mojo mojo:js_content_handler

define("main", [
  "console",
  "mojo/services/public/js/application",
  "services/js/test/echo_service.mojom"
], function(console, appModule, echoModule) {

  class EchoShellRequest extends appModule.Application {
    initialize(args) {
      var url = "file:/foo/bar/echo.js";
      var echoService = this.shell.connectToService(url, echoModule.EchoService);
      echoService.echoString("foo").then(function(result) {
        console.log("echoString(foo) => " + result.value);
      });
    }
  }
  return EchoShellRequest;
});
```

### Requesting a Service from an Application's ServiceProvider

The Shell's `connectToApplication()` method returns a JS ServiceProvider
object that serves as a proxy to a ServiceProvider implemented by the
target application. The ServiceProvider can be used to request services
from the target application and to provide services to the target application.

The echo_share.js and echo_share_target.js applications demonstrate this.


### Providing a Service with an Application's ServiceProvider

A complete application that unconditionally provides the EchoService
looks like this:

```javascript
#!mojo mojo:js_content_handler

define("main", [
  "mojo/services/public/js/application",
  "services/js/test/echo_service.mojom"
], function(appModule, echoModule) {

  class EchoService extends appModule.Application {
    acceptConnection(initiatorURL, serviceProvider) {
      function EchoServiceImpl(client) {
        this.echoString = function(s) {
          return Promise.resolve({value: s});
        };
      }
      serviceProvider.provideService(echoModule.EchoService, EchoServiceImpl);
    }
  }
  return EchoService;
});
```

As you can see, EchoServiceImpl is just a function that returns an
object that implements the methods in the Mojo EchoService
interface. If the EchoService defined a client interface, the factory
function's client parameter would be a proxy for the initiator's
client service. EchoService doesn't have a client so we could have
omitted this parameter.

Each time another application connects to this one, the EchoServiceImpl
function will be called. The caller will be able to run the
echoString() method and will get its response via a Promise.

The echo_share.js and echo_share_target.js applications demonstrate this.

## Final note

An initiator's serviceProvider object can be retained and used to
request or provide services at any time, not just from within
application's acceptConnection() method.