Hi, I'm looking into how to use String16 in blink.
`mojo.common.mojom.String16` is mapped to native `base::String` in Chromium, so how should we do for Blink?
Native typemapping is a low-effort fast path to converting IPC. The
trade-off is that such types are only usable for mojom in
(non-Blink) Chromium C++ code.
If you want to use String16 from Blink, you should define a wrapper mojom
struct:
// A wrapper struct to map between a native wide string and mojom strings
struct String16 {
string contents;
};
and then define separate typemaps for chromium and blink, mapping
mojom::String16 to something useful for each of those variants.
OK, the solution works, but seems to be a bit expensive.
I guess in this way, we are using std::string as internal storage? If we only pass String16 from Chromium to Chromium, then we need convert it to UTF-8 and then back to UTF-16.
I wonder if we could do something similar with the type map of 8-bit strings. i.e. mapping to native WTF::String in Blink and mapping to native std::string in chromium, and conversion only happens when sending from Blink to Chromium?
AFAICT there are relatively few legitimate uses (e.g. Windows UI code) of
string16s outside of Blink and direct Blink-consuming code. I think it
would be nice to replace uses of string16 with UTF8 strings when it's easy
enough to do. That would mean the blink side would explicitly convert to
utf8 before passing a string over, and we'd by convention only use UTF8
strings for a vast majority of IPCs.
In any case, an alternative approach to my previous suggestion would be to
define String16 as:
struct String16 {
array<uint8> data;
};
and just copy the data around with no encoding conversion.
Comment 1 by yzshen@chromium.org
, Jun 28 2016