You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Previously, the non-binary part of a message and the binary payloads in
a message were represented separately: the non-binary portion was
represented by a serde_json::Value, and could be converted to an
arbitrary data structure. That data structure would not include the
binary data or any indication that there is any binary data at all. The
binary data would be provided in a Vec<Vec<u8>>.
There were a few problems with this:
1. The original code only supported cases where the payload was a flat
array with some binary payloads in the root of the array, or a flat
object where the root of the object was a binary payload. Objects
with more complicated structure and binary data embedded in various
places in the structure were not supported.
2. Adding support for the above turned out to not be possible in a
useful way, because the ordering of the Vec<Vec<u8>> matters, and it
could never be clear where exactly in the possibly-complex structure
each binary payload belonged.
3. One of the useful features of the socket.io protocol is that it lets
users efficiently transmit binary data in addition to textual/numeric
data, and have that handled transparently by the protocol, with
either end of the connection believing that they just sent or
received a single mixed textual/numeric/binary payload. Separating
the non-binary from the binary negates that benefit.
This introduces a new type, PayloadValue, that behaves similarly to
serde_json::Value. The main difference is that it has a Binary variant,
which holds a numeric index and a Vec<u8>. This allows us to include
the binary data where the sender of that data intended it to be.
There is currently one wrinkle: serde_json does not appear to
consistently handle binary data; when serializing a struct with Vec<u8>,
I believe it will serialize it as an array of numbers, rather than
recognize that it's binary data. For now, I've included a Binary struct
that wraps a Vec<u8>, which can be included as the type of a binary
member, instead of using a Vec<u8> directly. Hopefully I'll be able to
figure out a better way to do this.
Unfinished tasks:
* Testing: I have no idea if this even works yet. All I've done is get
it to compile.
* Benchmarking: I've tried to ensure that I don't copy data any more
than the existing library does, but it's possible I've introduced some
performance regressions, so I'll have to look into that.
* Documentation: the documentation still references the old way of doing
things and needs to be updated.
Closes#276.
0 commit comments