mojo: first take on removing mojo_main_{chromium,standalone}.

mojo/public/cpp/application/application_runner.h

Index: mojo/public/cpp/application/application_runner.h
diff --git a/mojo/public/cpp/application/application_runner.h b/mojo/public/cpp/application/application_runner.h
new file mode 100644
index 0000000000000000000000000000000000000000..db26681a07d81caa7fab58a1674e6cb1daa06aa5
--- /dev/null
+++ b/mojo/public/cpp/application/application_runner.h
@@ -0,0 +1,29 @@
+// Copyright 2014 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.
+
+#ifndef MOJO_PUBLIC_APPLICATION_APPLICATION_RUNNER_H_
+#define MOJO_PUBLIC_APPLICATION_APPLICATION_RUNNER_H_
+
+#include "mojo/public/cpp/system/core.h"
+
+namespace mojo {
+
+class ApplicationDelegate;
+
+class ApplicationRunner {
+ public:
+  ApplicationRunner();
+  ~ApplicationRunner();
+
+  void take_delegate(ApplicationDelegate* delegate);

[DaveMoore, 2014/08/07 01:54:33]

take_delegate()? Why not set_delegate()? And why is the declaration different
from ApplicationRunnerChromium? And what cases don't have the delegate?

[tim (not reviewing), 2014/08/07 17:13:21]

I wanted to convey ownership without being able to have scoped_ptr, except in
ARChromium where I can, which is why the two declarations are different. If this
is more awkward sounding than anything else we can change it to set_() with raw
pointers in both places. But ownership is important, because we want to control
when the different pieces are destroyed relative to each other.

I was originally thinking the delegate would be a constructor parameter, since
all the apps I've come across so far use a delegate. But Darin brought up the
fact that apps that do not vend services do not need a delegate, and that might
be a common case. (discussion @
https://docs.google.com/a/chromium.org/document/d/1Fmf6HLldq8tXQkJyaact68G_NK...
). 

Right now ApplicationImpl isn't really built to handle a null delegate, whether
you are vending services or connecting to services (e.g
ConfigureOutgoingConnection).

[DaveMoore, 2014/08/07 18:12:36]

What I don't like about it is that ARC inherits from AR, so it ends up with both
methods visible to clients. That seems confusing.

On 2014/08/07 17:13:21, timsteele wrote:

[tim (not reviewing), 2014/08/07 18:46:49]

Oh, but it doesn't inherit :) I explicitly avoided inheritance between AR, ARC,
and ApplicationImpl because I didn't see a need.  Note that AR and ARC are part
of different targets. You only get the one from the application target you
linked against, which now also implicitly brings in the correct environment_
target.

[darin (slow to review), 2014/08/07 20:08:48]

take_delegate() bothers me too :)

Why do you need to control the lifetime of the ApplicationDelegate? How about we
just say that it has to outlive the ApplicationRunner?

[tim (not reviewing), 2014/08/07 22:05:32]

Will rename. I guess I was thinking the ApplicationRunner would outlive the
delegate, and the delegate would be destroyed before things like Environment and
AtExitManager. One Runner per invocation of Run() that blocks until everything
is done and gone seemed simple to me.

I suppose we could add an ApplicationDelegate::Shutdown as the object lifetime
counterpart to ApplicationDelegate::Initialize, and say the delegate outlives
the Runner while having a chance to clean up before the world disappears.

+  MojoResult Run(MojoHandle shell_handle);
+
+ private:
+  // Optional delegate.
+  ApplicationDelegate* delegate_;
+};
+
+}  // namespace mojo
+
+#endif  // MOJO_PUBLIC_APPLICATION_APPLICATION_RUNNER_H_