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
wRPC values will always require a multiplexed connection and appropriate APIs for transmission and receival (due to values potentially containing nested async values, like streams or futures) - there may be use cases, however, where it may be desired to directly encode/decode wRPC values to/from single byte buffer - for example, for persistent storage. For those use cases, I propose to introduce pack/unpack functionality, which works the following way:
All values can be packed - producing a single byte buffer with fully resolved/ready async values, if any
packed values can always be unpacked
Only fully resolved values can be packed (meaning that all incoming streams are fully received and finished and all futures are "ready" and their result is known). Packing operation may never complete if value being packed never resolves - therefore, packing operation MUST provide an API, which takes in a user-provided timeout.
Just like in "core wRPC":
resolved futures future<T> are encoded as option::some variant of option<T>
resolved streams stream<T> are encoded as chunk_count:<core:uN> (chunk:<vec<T>>)^chunk_length with or without the "end" 0-length chunk. The special case of a "ready" empty stream is encoded as a stream containing a single, empty chunk
wRPC values will always require a multiplexed connection and appropriate APIs for transmission and receival (due to values potentially containing nested async values, like streams or futures) - there may be use cases, however, where it may be desired to directly encode/decode wRPC values to/from single byte buffer - for example, for persistent storage. For those use cases, I propose to introduce
pack
/unpack
functionality, which works the following way:future<T>
are encoded asoption::some
variant ofoption<T>
stream<T>
are encoded aschunk_count:<core:uN> (chunk:<vec<T>>)^chunk_length
with or without the "end" 0-length chunk. The special case of a "ready" empty stream is encoded as a stream containing a single, empty chunkBinary.md
cc @protochron
The text was updated successfully, but these errors were encountered: