Expose some sky_viewer plumbing to allow for reuse

Expose some sky_viewer plumbing to allow for reuse

This CL exposes some of the plumbing of sky_viewer in preparation for a
followup in which a content handler that handles sky *packaged* apps will share
this plumbing. In particular:

- SkyViewerBase: Abstract superclass for Mojo apps that are intended to be
content handlers of some kind for Sky. Handles the details of setting up the
Sky environment (e.g., blink::initialize()), but leaves it up to subclasses to
instantiate a content handler.

- SkyLoader: Loads and runs a Sky file at |url| within the context of the
currently-running Mojo application, which is assumed to have set up the Sky
environment properly.

BUG=

[blundell, 2015-04-16 14:04:22]

blundell@chromium.org changed reviewers:
+ eseidel@chromium.org

[blundell, 2015-04-16 14:09:54]

https://codereview.chromium.org/1085853002/ is the "consumer" of this CL.

[abarth-chromium, 2015-04-16 20:54:34]

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

[abarth-chromium, 2015-04-16 20:54:35]

I don't think this change makes sense.  We only want to have one binary in the
ecosystem that contains //sky/engine.  This CL implies that there will be two
binaries that contain //sky/engine: one for packaged apps and one for
non-packaged apps.

Instead, the package handler should be able to compose with an arbitrary content
handler via Mojo messaging (i.e., without needing to link with it).

[blundell, 2015-04-17 12:27:15]

On 2015/04/16 20:54:35, abarth wrote:
> I don't think this change makes sense.  We only want to have one binary in the
> ecosystem that contains //sky/engine.  This CL implies that there will be two
> binaries that contain //sky/engine: one for packaged apps and one for
> non-packaged apps.
> 
> Instead, the package handler should be able to compose with an arbitrary
content
> handler via Mojo messaging (i.e., without needing to link with it).

Hi Adam,

Your understanding of the purpose of this CL is correct, and I agree that the
approach that you propose is much cleaner. I went with that approach initially:
see
https://codereview.chromium.org/1085853002/diff/40001/services/sky_packaged_a...
(line 130). However, as qsr@ pointed out, that approach has the flaw that the
Sky (or whatever) app that is connected to is effectively anonymous, as its URL
becomes http://localhost:<port>/main.sky. Thus, any apps that that Sky app
connected to wouldn't know who was connecting to them. This seemed to me to be a
fatal flaw for that approach. Do you see a way around this problem in that
approach (or did you have something different in mind)?

Thanks,

Colin

[abarth-chromium, 2015-04-17 16:25:55]

On 2015/04/17 at 12:27:15, blundell wrote:
> Your understanding of the purpose of this CL is correct, and I agree that the
approach that you propose is much cleaner. I went with that approach initially:
see
https://codereview.chromium.org/1085853002/diff/40001/services/sky_packaged_a...
(line 130). However, as qsr@ pointed out, that approach has the flaw that the
Sky (or whatever) app that is connected to is effectively anonymous, as its URL
becomes http://localhost:<port>/main.sky. Thus, any apps that that Sky app
connected to wouldn't know who was connecting to them. This seemed to me to be a
fatal flaw for that approach. Do you see a way around this problem in that
approach (or did you have something different in mind)?

Rather than spinning up a local web server to expose the contents of the
package, we should instead have the package handler implement the
url_loader.mojom protocol.  For example, we could introduce something like
ServiceWorker [1] to the Mojo system to let applications work offline.  The
package handler would then be like a ServiceWorker that serviced some URL
requests from inside the package instead of from the network.

[1] http://www.html5rocks.com/en/tutorials/service-worker/introduction/

[blundell, 2015-04-20 15:12:25]

On 2015/04/17 16:25:55, abarth wrote:
> On 2015/04/17 at 12:27:15, blundell wrote:
> > Your understanding of the purpose of this CL is correct, and I agree that
the
> approach that you propose is much cleaner. I went with that approach
initially:
> see
>
https://codereview.chromium.org/1085853002/diff/40001/services/sky_packaged_a...
> (line 130). However, as qsr@ pointed out, that approach has the flaw that the
> Sky (or whatever) app that is connected to is effectively anonymous, as its
URL
> becomes http://localhost:%3Cport%3E/main.sky. Thus, any apps that that Sky app
> connected to wouldn't know who was connecting to them. This seemed to me to be
a
> fatal flaw for that approach. Do you see a way around this problem in that
> approach (or did you have something different in mind)?
> 
> Rather than spinning up a local web server to expose the contents of the
> package, we should instead have the package handler implement the
> url_loader.mojom protocol.  For example, we could introduce something like
> ServiceWorker [1] to the Mojo system to let applications work offline.  The
> package handler would then be like a ServiceWorker that serviced some URL
> requests from inside the package instead of from the network.
> 
> [1] http://www.html5rocks.com/en/tutorials/service-worker/introduction/

That's an intriguing suggestion. I opened up consideration of this issue on
mojo-dev:
https://groups.google.com/a/chromium.org/forum/#!topic/mojo-dev/OKcv1eBy7CA.