[Chromoting] The daemon process now starts the networking process and passes the host configuration…

remoting/host/win/worker_process_launcher.h

Index: remoting/host/win/worker_process_launcher.h
diff --git a/remoting/host/win/worker_process_launcher.h b/remoting/host/win/worker_process_launcher.h
index f57ecd88e36493e041f254e353f3e4025d2d354d..de0e226a6841979a540ab42f16751d390dcc5f64 100644
--- a/remoting/host/win/worker_process_launcher.h
+++ b/remoting/host/win/worker_process_launcher.h
@@ -28,6 +28,8 @@ class Message;
 
 namespace remoting {
 
+class WorkerProcessDelegate;
+
 // Launches a worker process that is controlled via an IPC channel. All
 // interaction with the spawned process is through the IPC::Listener and Send()
 // method. In case of error the channel is closed and the worker process is
@@ -52,25 +54,20 @@ class WorkerProcessLauncher
 
     // Terminates the worker process with the given exit code.
     virtual void DoKillProcess(DWORD exit_code) = 0;
-
-    // Notifies that a client has been connected to the channel.
-    virtual void OnChannelConnected() = 0;
-
-    // Processes messages sent by the client.
-    virtual bool OnMessageReceived(const IPC::Message& message) = 0;
   };
 
-  // Creates the launcher.
-  // |delegate| will be able to receive messages sent over the channel once
-  // the worker has been started and until it is stopped by Stop() or an error
-  // occurs.
+  // Creates the launcher that outsources specific of launching the worker to

[Wez, 2012/08/21 00:18:57]

nit: I think you mean you're creating a launcher that will use the supplied
delegate to actually manage the worker process, and the supplied
WorkerProcessDelegate to handle IPCs?

[alexeypa (please no reviews), 2012/08/23 23:53:01]

Done.

+  // |launcher_delegate|. |worker_delegate| will be able to receive messages
+  // sent over the channel once the worker has been started and until it is
+  // stopped by Stop() or an error occurs.
   //
   // |stopped_callback| and |main_task_runner| are passed to the underlying
   // |Stoppable| implementation. The caller should call all the methods on this
   // class on the |main_task_runner| thread. |ipc_task_runner| is used to
   // perform background IPC I/O.
   WorkerProcessLauncher(
-      Delegate* delegate,
+      Delegate* launcher_delegate,
+      WorkerProcessDelegate* worker_delegate,

[Wez, 2012/08/21 00:18:57]

Why do we not just use IPC::Listener here?

[alexeypa (please no reviews), 2012/08/21 17:16:36]

Because IPC::Listener is a different interface. IPC::Listener has more methods
that we don't use or support.

[Wez, 2012/08/24 22:20:37]

IPC::Listener just has OnMessageReceived, OnChannelConnected and OnChannelError
(cross-platform); the only one you don't use is OnChannelError, and in any case
the interface is designed such that implementations need not override calls they
don't care about.

[alexeypa (please no reviews), 2012/08/27 23:16:41]

Yes, IPC::Listener is very similar but different interface. There are no
consumers expecting IPC::Listener, so using IPC::Listener has cost but no
advantages.

[Wez, 2012/08/30 20:36:04]

The advantage is simply that we don't define a new interface that just provides
a subset of the functionality of an existing one.

[alexeypa (please no reviews), 2012/08/30 23:15:13]

It provides different functionality, that is not a subset of IPC::Listener.
OnChannelConnected() for example does not have client's PID. This is done on
purpose. There is no OnChannelError(). That is because the error signalling is
different, so supporting OnChannelError() on either side will be wasted code.
There are also OnChannelDenied() and OnChannelDenied() on POSIX
(WorkedProcessDelegate is cross-platform) that we don't need here.

Imagine it would be IPC::Listener. You would be the first one who asked me to
document all of those differences.

[Wez, 2012/08/31 00:23:04]

Those are all optional for the IPC::Listener implementation to override, though.
 
True, but it would be a one or two line comment in this implementation, rather
than a whole new interface. ;)

[alexeypa (please no reviews), 2012/08/31 21:26:55]

Implemented may mistakenly assume that the optional methods are supported and
add code that relies on them.
A comment does not enforce the difference.

       const base::Closure& stopped_callback,
       scoped_refptr<base::SingleThreadTaskRunner> main_task_runner,
       scoped_refptr<base::SingleThreadTaskRunner> ipc_task_runner);
@@ -79,8 +76,9 @@ class WorkerProcessLauncher
   // Starts the worker process.
   void Start(const std::string& pipe_sddl);
 
-  // Sends an IPC message to the worker process. This method can be called only
-  // after successful Start() and until Stop() is called or an error occurred.
+  // Sends an IPC message to the worker process. The message will be silently
+  // dropped if Send() is called before Start() or after stutdown has been
+  // initiated.
   void Send(IPC::Message* message);
 
   // base::win::ObjectWatcher::Delegate implementation.
@@ -104,7 +102,8 @@ class WorkerProcessLauncher
   // Generates random channel ID.
   std::string GenerateRandomChannelId();
 
-  Delegate* delegate_;
+  Delegate* launcher_delegate_;
+  WorkerProcessDelegate* worker_delegate_;
 
   // The main service message loop.
   scoped_refptr<base::SingleThreadTaskRunner> main_task_runner_;