When inspector emits a message, to be sent to the client, we copy those bytes a
number of times. First, V8 serializes the message to CBOR. Next, it converts it
to JSON. We then copy this into a C++ string, then into a Zig slice. We create
one final copy (with websocket framing) to add to the write queue.
Something similar, but a little less extreme, happens with incoming messages.
By supporting CBOR messages directly, we not only reduce the amount of copying,
but also leverage our [more tightly scoped and re-used] arenas.
CBOR is essentially a standardized MessagePack. Two functions, jsonToCbor and
cborToJson have been introduced to take our incoming JSON message and convert it
to CBOR and, vice-versa. V8 automatically detects that the message is CBOR and,
if the incoming message is CBOR, the outgoing message is CBOR also.
While v8 is spec-compliant, it has specific expectations and behavior. For
example, it never emits a fixed-length array / map - it's always an infinite
array / map (with a special "break" code at the end). For this reason, our
implementation is not complete, but rather designed to work with what v8 does
and expects.
Another example of this is, and I don't understand why, some of the
incoming messages have a "params" field. V8 requires this to be a CBOR embedded
data field (that is, CBOR embedded into CBOR). If we pass an array directly,
while semantically the same, it'll fail. I guess this is how Chrome serializes
the data, and rather than just reading the data as-is, v8 asserts that it's
encoded in a particularly flavor. Weird. But we have to accommodate that.
Capture its unique properties:
1- instances are falsy, and
2- instance can be called as a function
The behavior is used for browser detection (i.e. duckduckgo treats us as a
legacy browser because we document.all != false)
There's ambiguity in mapping due to the flexible nature of JavaScript. Hopefully
most types are unambiguous, like a string or am *parser.Node.
We need to "probe" each field to see if it's a possible candidate for the JS
value. On a perfect match, we stop probing and set the appropriate union field.
There are 2 levels of possible matches: candidate and coerce. A "candidate"
match has higher precedence. This is necessary because, in JavaScript, a lot
of things can be coerced to a lot of other, seemingly wrong, things.
For example, say we have this union:
a: i32,
b: bool,
Field `a` is a perfect match for the value 123. And field b is a coerce match
(because, yes, 123 can be coerced to a boolean). So we map it to `a`.
Field `a` is a candidate match for the value 34.2, because float -> int are both
"Numbers" in JavaScript. And field b is a coerce match. So we map it to `a`.
Both field `a` and field `b` are coerce matches for "hello". So we map it to `a`
because it's declared first (this relies on how Zig currently works, but I don't
think the ordering of type declarations is guaranteed, so that's an issue).
Remove Env from caller, and don't store Env in isolate. We don't need it, we
can execute all runtime code from the Executor (which we store a pointer to
in the v8.Context)
