OLD | NEW |
---|---|
(Empty) | |
1 // Copyright 2017 The Chromium Authors. All rights reserved. | |
2 // Use of this source code is governed by a BSD-style license that can be | |
3 // found in the LICENSE file. | |
4 | |
5 #ifndef CONTENT_BROWSER_ANDROID_STRING_MESSAGE_CODEC_H_ | |
6 #define CONTENT_BROWSER_ANDROID_STRING_MESSAGE_CODEC_H_ | |
7 | |
8 #include "base/strings/string16.h" | |
9 #include "content/common/content_export.h" | |
10 | |
11 namespace content { | |
12 | |
13 // To support exposing HTML message ports to Java, it is necessary to be able | |
14 // 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
| |
15 // That format is an implementation detail of V8, but we cannot invoke V8 in | |
16 // the browser process. Rather than IPC over to the renderer process to execute | |
17 // the V8 serialization code, we duplicate some of the serialization logic | |
18 // (just for simple string messages) here. This is a trade-off between overall | |
19 // complexity / performance and code duplication. Fortunately, we only need to | |
20 // handle string messages and this serialization format is static, as it is a | |
21 // format we currently persist to disk via IndexedDB. | |
22 | |
23 CONTENT_EXPORT base::string16 EncodeStringMessage(const base::string16& data); | |
24 | |
25 CONTENT_EXPORT bool DecodeStringMessage(const base::string16& encoded_data, | |
26 base::string16* result); | |
27 | |
28 } // namespace content | |
29 | |
30 #endif // CONTENT_BROWSER_ANDROID_STRING_MESSAGE_CODEC_H_ | |
OLD | NEW |