Optionally have MessagePort pass data as base::Value, part 1.

android_webview/browser/aw_message_port_message_filter.cc

Index: android_webview/browser/aw_message_port_message_filter.cc
diff --git a/android_webview/browser/aw_message_port_message_filter.cc b/android_webview/browser/aw_message_port_message_filter.cc
index fc2d314496c1c7d716376d85f5f9cccca3657a79..b19b344651421d93db02ca35035e7ec5a3532d64 100644
--- a/android_webview/browser/aw_message_port_message_filter.cc
+++ b/android_webview/browser/aw_message_port_message_filter.cc
@@ -7,6 +7,7 @@
 #include "android_webview/browser/aw_browser_context.h"
 #include "android_webview/common/aw_message_port_messages.h"
 #include "content/public/browser/message_port_provider.h"
+#include "content/public/common/message_port_types.h"
 
 using content::BrowserThread;
 using content::MessagePortProvider;
@@ -46,7 +47,10 @@ void AwMessagePortMessageFilter::OnConvertedAppToWebMessage(
     const base::string16& message,
     const std::vector<int>& sent_message_port_ids) {
 
-  MessagePortProvider::PostMessageToPort(msg_port_id, message,
+  // TODO(mek): Bypass the extra roundtrip and just send the unconverted message
+  // to the renderer directly.

[sgurun-gerrit only, 2015/02/27 03:17:36]

I don't know what you ended up designing for converting messages for
navigator.connect, but I am not very sure if it will work in webview case. let's
first talk about it before doing anything.

also, I don't think we want to introduce v8 usages in browser side for
multiprocess case. 

[Marijn Kruisselbrink, 2015/02/27 05:00:57]

Well, messages send from the browser to a MessagePort (which this code and this
TODO is about) are easy in any solution. There is no need for an extra
roundtrip, the browser can just send the base::Value to the MessagePort, and
with this CL the MessagePort will then do the conversion.

For the reverse, sending messages from a MessagePort to code in the browser
process, what I've implemented here won't work for the android webview case,
because of the extra requirements you had for being able to freely transfer
around both ends of these channels.

I'll happily talk more, but I'm not sure why figuring out a complete solution
that works for both android webview and navigator.connect should block
implementing a temporary solution for navigator.connect (it certainly doesn't
seem to have stopped implementing the webview specific "hacks").
Of course. I have no plans whatsoever to add any kind of v8 usage in the browser
process.

[sgurun-gerrit only, 2015/02/27 18:06:50]

ok I just wanted to understand what overall solution you came up with after the
design document you provided, since I did not hear again.  
I think you misunderstood. Where did I imply we should block it? I wanted to
make sure any new work you are doing is compatible with anything we are
planning.

[Marijn Kruisselbrink, 2015/02/27 18:17:51]

Yes, it would be nice to be kept in the loop on anything you are planning. I
guess I misunderstood "let's first talk [...] before doing anything" as meaning
you wouldn't approve this CL (and future ones needed for navigator.connect)
until we've fully worked out a solution that works for both.

[sgurun-gerrit only, 2015/02/27 18:33:25]

my comment is wrt to the webview that you mentioned in TODO. 

+  MessagePortProvider::PostMessageToPort(msg_port_id,
+      content::MessagePortMessage(message),
       sent_message_port_ids);
 }
 
@@ -76,12 +80,13 @@ void AwMessagePortMessageFilter::SendClosePortMessage(int message_port_id) {
 
 void AwMessagePortMessageFilter::SendMessage(
     int msg_port_route_id,
-    const base::string16& message,
+    const content::MessagePortMessage& message,
     const std::vector<int>& sent_message_port_ids) {
+  DCHECK(message.is_string());
   Send(new AwMessagePortMsg_WebToAppMessage(
       route_id_,
       msg_port_route_id, // same as the port id
-      message, sent_message_port_ids));
+      message.message_as_string, sent_message_port_ids));
 }
 
 void AwMessagePortMessageFilter::SendMessagesAreQueued(int route_id) {