[Chromoting] Plugin message in JingleMessage

remoting/protocol/jingle_messages.h

Index: remoting/protocol/jingle_messages.h
diff --git a/remoting/protocol/jingle_messages.h b/remoting/protocol/jingle_messages.h
index 08e538a8a6a576653a2e0e4cd08fbfb300519f0c..4853226620699041ae46caecea6e2d90d4a23045 100644
--- a/remoting/protocol/jingle_messages.h
+++ b/remoting/protocol/jingle_messages.h
@@ -101,6 +101,10 @@ struct JingleMessage {
   // Content of session-info messages.
   std::unique_ptr<buzz::XmlElement> info;
 
+  // Content of plugin message. The node is read or written by all plugins, and

[Sergey Ulanov, 2016/12/12 23:00:03]

There can be more than one plugin, so I think this should be a vector.

[Hzj_jie, 2016/12/13 00:20:51]

Then we will need extra logic to decide which piece of data should be sent to a
certain plugin in JingleSession, which indeed can be placed in plugins
themselves. I.e. A plugin get entire plugin data, and decide which subnode it
should read from or write to.

[Sergey Ulanov, 2016/12/14 01:31:50]

I don't think it would increase complexity much. The dispatching code could look
as follows:
  for (auto& msg : plugin_messages) {
    for (auto& plugin : plugins_) { 
      if (plugin->HandleMessage(msg)) 
        break;
    }
  }

but feel free to keep the current approach (see the comment below).
I see. Then I think <plugin> is not the best name, as it stores information for
multiple plugins. <plugins> would be better, but still not very clear. Maybe
call it <attachements>?

[Hzj_jie, 2016/12/14 20:03:48]

Yes, "attachments" is definitely good. Updated.

+  // ActionType independent.
+  std::unique_ptr<buzz::XmlElement> plugin_message;
+
   // Value from the <reason> tag if it is present in the
   // message. Useful mainly for session-terminate messages, but Jingle
   // spec allows it in any message.