Protocol-level changes required to support PIN-less authentication.

remoting/protocol/client_control_dispatcher.cc

Index: remoting/protocol/client_control_dispatcher.cc
diff --git a/remoting/protocol/client_control_dispatcher.cc b/remoting/protocol/client_control_dispatcher.cc
index 580ea28a20ed126a4b7985e48a2decd6932da6d2..fee63dcfc1cc8ff3a2c3f1388e315914915f90e1 100644
--- a/remoting/protocol/client_control_dispatcher.cc
+++ b/remoting/protocol/client_control_dispatcher.cc
@@ -64,6 +64,16 @@ void ClientControlDispatcher::SetCapabilities(
     const Capabilities& capabilities) {
   ControlMessage message;
   message.mutable_capabilities()->CopyFrom(capabilities);
+}
+
+void ClientControlDispatcher::RequestPairing(
+    const PairingRequest& pairing_request,
+    const base::Callback<void(const PairingReply&)>& callback) {
+  // TODO(jamiewalch): Add a request id to the pairing requests to allow us to
+  // route the response to the correct callback.
+  latest_pairing_callback_ = callback;
+  ControlMessage message;
+  message.mutable_pairing_request()->CopyFrom(pairing_request);
   writer_.Write(SerializeAndFrameMessage(message), base::Closure());
 }
 
@@ -79,6 +89,11 @@ void ClientControlDispatcher::OnMessageReceived(
     client_stub_->SetCapabilities(message->capabilities());
   } else if (message->has_cursor_shape()) {
     client_stub_->SetCursorShape(message->cursor_shape());
+  } else if (message->has_pairing_reply()) {
+    if (!latest_pairing_callback_.is_null()) {

[alexeypa (please no reviews), 2013/05/09 02:49:20]

nit: LOG(WARNING) << some message if no callback available.

[Jamie, 2013/05/09 17:59:52]

No longer needed in light of your and Renato's comments about this belonging in
ClientStub.

+      latest_pairing_callback_.Run(message->pairing_reply());
+      latest_pairing_callback_.Reset();

[alexeypa (please no reviews), 2013/05/09 02:49:20]

I'd say this logic belongs to |client_stub|. Up until now
ClientControlDispatcher was simply passing messages to the corresponding stub.
This CL makes it more complicated. 

[rmsousa, 2013/05/09 03:55:02]

Agreed. ClientStub is already essentially a callback interface. No point using a
different callback mechanism just for this message.

Ideally it should look like SetCursorShape or InjectClipboardEvent - go all the
way up to ClientStub (or PairingStub), ChromotingClient, ChromotingInstance,
Webapp. (yes, those are quite a few classes to pipe through).

There is no way for the webapp to pass in a bound callback on the RequestPairing
call, so it already has to be able to receive a "stateless" RespondToPairing
message from the client plugin and route it properly. There's no need to
duplicate such routing (and deal with cases such as orphan replies, double
requests, etc, etc) here as well.

[Jamie, 2013/05/09 17:59:52]

Fair enough. It gets rid of a TODO and makes this CL more self-contained as
well. Done.

+    }
   } else {
     LOG(WARNING) << "Unknown control message received.";
   }