HTML MessagePort as mojo::MessagePipeHandle

content/browser/android/string_message_codec.h

Index: content/browser/android/string_message_codec.h
diff --git a/content/browser/android/string_message_codec.h b/content/browser/android/string_message_codec.h
new file mode 100644
index 0000000000000000000000000000000000000000..eb4254a593e11f6e4cf9e8c7145d449a559e2372
--- /dev/null
+++ b/content/browser/android/string_message_codec.h
@@ -0,0 +1,30 @@
+// Copyright 2017 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_BROWSER_ANDROID_STRING_MESSAGE_CODEC_H_
+#define CONTENT_BROWSER_ANDROID_STRING_MESSAGE_CODEC_H_
+
+#include "base/strings/string16.h"
+#include "content/common/content_export.h"
+
+namespace content {
+
+// To support exposing HTML message ports to Java, it is necessary to be able
+// encode and decode message data using the same serialization format as V8.

[kinuko, 2017/02/09 06:21:30]

nit: to be able encode -> to be able to encode

+// That format is an implementation detail of V8, but we cannot invoke V8 in
+// the browser process. Rather than IPC over to the renderer process to execute
+// the V8 serialization code, we duplicate some of the serialization logic
+// (just for simple string messages) here. This is a trade-off between overall
+// complexity / performance and code duplication. Fortunately, we only need to
+// handle string messages and this serialization format is static, as it is a
+// format we currently persist to disk via IndexedDB.
+
+CONTENT_EXPORT base::string16 EncodeStringMessage(const base::string16& data);
+
+CONTENT_EXPORT bool DecodeStringMessage(const base::string16& encoded_data,
+                                        base::string16* result);
+
+}  // namespace content
+
+#endif  // CONTENT_BROWSER_ANDROID_STRING_MESSAGE_CODEC_H_