Propagate connection state from networking layer to UI.

remoting/protocol/connection_to_host.cc

Index: remoting/protocol/connection_to_host.cc
diff --git a/remoting/protocol/connection_to_host.cc b/remoting/protocol/connection_to_host.cc
index 5794c50216f15daff92d3da49b1890f40c3e2612..0ebc3c0d8316fa95b459fb2142f69f03642a18c5 100644
--- a/remoting/protocol/connection_to_host.cc
+++ b/remoting/protocol/connection_to_host.cc
@@ -209,6 +209,21 @@ void ConnectionToHost::OnSessionRouteChange(const std::string& channel_name,
                                             const TransportRoute& route) {
 }
 
+void ConnectionToHost::OnSessionChannelReady(const std::string& channel_name,
+                                             bool ready) {
+  if (ready) {
+    not_ready_channels_.erase(channel_name);

[Wez, 2012/07/17 01:47:50]

Should we set |not_ready_channels_| to contain all the channels, initially, so
that the "ready" state is accurate at start of day?

[Sergey Ulanov, 2012/07/18 00:52:07]

I don't think it's necessary because we know that each channels is ready at some
point before state is set to CONNECTED.

+  } else if (!ready) {
+    not_ready_channels_.insert(channel_name);
+  }
+
+  if (ready && not_ready_channels_.size() == 0U) {

[Wez, 2012/07/17 01:47:50]

Can't this entire block be
event_callback_.OnConnectionReady(not_ready_channels.empty())? The only downside
is that you might see multiple callbacks with the same state, but so long as we
state that callbacks must cope with that, I think that's fine.

[Sergey Ulanov, 2012/07/18 00:52:07]

Done.

+    event_callback_->OnConnectionReady(true);
+  } else if (!ready && not_ready_channels_.size() == 1U) {
+    event_callback_->OnConnectionReady(false);
+  }
+}
+
 ConnectionToHost::State ConnectionToHost::state() const {
   return state_;
 }