Set the initial resolution of an RDP session to the client screen resolution if it is available.

remoting/client/plugin/chromoting_instance.cc

Index: remoting/client/plugin/chromoting_instance.cc
diff --git a/remoting/client/plugin/chromoting_instance.cc b/remoting/client/plugin/chromoting_instance.cc
index 057c4a1efe39e4ea232e748bd7a71f710fb6268e..67cad65e4d54819c971c8b670036519bd5c1b826 100644
--- a/remoting/client/plugin/chromoting_instance.cc
+++ b/remoting/client/plugin/chromoting_instance.cc
@@ -139,6 +139,9 @@ const char ChromotingInstance::kApiFeatures[] =
     "notifyClientDimensions notifyClientResolution pauseVideo pauseAudio "
     "asyncPin thirdPartyAuth";
 
+const char ChromotingInstance::kRequestedCapabilities[] = "";
+const char ChromotingInstance::kSupportedCapabilities[] = "";
+
 bool ChromotingInstance::ParseAuthMethods(const std::string& auth_methods_str,
                                           ClientConfig* config) {
   std::vector<std::string> auth_methods;
@@ -187,6 +190,9 @@ ChromotingInstance::ChromotingInstance(PP_Instance pp_instance)
   data->SetInteger("apiVersion", kApiVersion);
   data->SetString("apiFeatures", kApiFeatures);
   data->SetInteger("apiMinVersion", kApiMinMessagingVersion);
+  data->SetString("requestedCapabilities", kRequestedCapabilities);

[Sergey Ulanov, 2013/04/16 08:38:53]

It's not clear to me what's the difference between these two attributes, and
client code doesn't make it clearer. Given that requestedCapabilities is ignored
by the webapp, do we need it at all?

[alexeypa (please no reviews), 2013/04/16 22:06:11]

"requested" capabilities are the ones that need to be supported by both plugin
and webapp to work. I.e. the intersection of "requested" capabilities supported
by the plugin and webapp will be sent to the host.

"supported" capabilities are the ones that do not require any special handling
in the webapp. The webapp will pass them through in most of the cases. The
reason they are passed to the webapp at all is that the latter should be able to
"veto" them in case if we need to fix anything after the client plugin has been
released. 
Declarations of both constants are documented. See chromoting_instance.h. 
We still need the webapp to be ready to handle them. We could remove them from
the plugin but it is just around five lines of code and it serves as
documentation/guidelines how the "requested" capabilities should be handled.

+  data->SetString("supportedCapabilities", kSupportedCapabilities);
+
   PostChromotingMessage("hello", data.Pass());
 }
 
@@ -293,6 +299,16 @@ void ChromotingInstance::HandleMessage(const pp::Var& message) {
       config.fetch_secret_callback =
           base::Bind(&ChromotingInstance::FetchSecretFromString, shared_secret);
     }
+
+    // Read the list of capabilities, if any.
+    base::ListValue* capabilities = NULL;
+    if (data->GetList("capabilities", &capabilities)) {

[Sergey Ulanov, 2013/04/16 08:38:53]

Here capablities are represented as list, while requestedCapabilities and
supportedCapabilites are passed as strings.

[alexeypa (please no reviews), 2013/04/16 22:06:11]

Done.

+      if (!config.capabilities.FromListValue(*capabilities)) {
+        LOG(ERROR) << "capabilities are invalid in connect().";
+        return;
+      }
+    }
+
     Connect(config);
   } else if (method == "disconnect") {
     Disconnect();
@@ -474,6 +490,12 @@ void ChromotingInstance::OnConnectionReady(bool ready) {
   PostChromotingMessage("onConnectionReady", data.Pass());
 }
 
+void ChromotingInstance::SetCapabilities(const std::string& capabilities) {
+  scoped_ptr<base::DictionaryValue> data(new base::DictionaryValue());
+  data->SetString("capabilities", capabilities);
+  PostChromotingMessage("setCapabilities", data.Pass());
+}
+
 void ChromotingInstance::FetchSecretFromDialog(
     const protocol::SecretFetchedCallback& secret_fetched_callback) {
   // Once the Session object calls this function, it won't continue the