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

content/public/common/message_port_types.h

+// Copyright 2015 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef CONTENT_PUBLIC_COMMON_MESSAGE_PORT_TYPES_H_
+#define CONTENT_PUBLIC_COMMON_MESSAGE_PORT_TYPES_H_
+
+#include <vector>
+
+#include "base/memory/scoped_ptr.h"
+#include "base/strings/string16.h"
+#include "base/values.h"
+#include "content/common/content_export.h"
+
+namespace content {
+
+// Struct representing a message sent across a message port. This struct hides
+// the fact that messages can be serialized/encoded in multiple ways from code
+// that doesn't care about the message contents.
+struct CONTENT_EXPORT MessagePortMessage {
+  MessagePortMessage();
+  explicit MessagePortMessage(const base::string16& message);
+  explicit MessagePortMessage(scoped_ptr<base::Value> message);
+  MessagePortMessage(const MessagePortMessage& other);
+  MessagePortMessage& operator=(const MessagePortMessage& other);
+  ~MessagePortMessage();
+
+  bool is_string() const { return !message_as_string.empty(); }
+  bool is_value() const { return !message_as_value.empty(); }
+  const base::Value* as_value() const;
+
+  // Message serialized using blink::WebSerializedScriptValue. Only one of
+  // |message_as_string| and |message_as_value| should be non-empty.
+  base::string16 message_as_string;
+  // Message as a base::Value. This is either an empty list or a list
+  // containing exactly one item.
+  base::ListValue message_as_value;

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

can't base::listvalue carry a string? why introduce the MessagePortMessage? is
it just temporary.

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

Yes, base::ListValue could carry a string. It would require converting the UTF16
string to UTF8 (and vice versa), which since these are not even really strings
might have weird effects. I'm also not sure how that would be better though.
Yes, instead of base::Value + base::string16 MessagePortMessage could be a
base::Value + some enum to define what type is stored in the value (or some
other hack to store that information), but it seems much clearer to just keep
this separated. One field for messages that are encoded as
SerializedScriptValue, and one field for messages that are send as base::Value.

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

are you sure this is right? base::value seems to allow setting and getting a
string16.

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

If you look at the base::string16 methods of base::StringValue, you see they use
UTF16ToUTF8 when setting and UTF8ToUTF16 when getting.

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

huh, that is interesting. I guess something to address in future.

+};
+
+}  // namespace content
+
+#endif  // CONTENT_PUBLIC_COMMON_MESSAGE_PORT_TYPES_H_