Closed BlackAsLight closed 3 weeks ago
Attention: Patch coverage is 90.26275%
with 126 lines
in your changes missing coverage. Please review.
Project coverage is 96.55%. Comparing base (
065296c
) to head (ec68c5c
). Report is 1 commits behind head on main.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
I wonder if these need to be classes when they both don't have any instance states.
How about making them just deocde
and encode
functions? That mirrors the structure of std/msgpack
I wonder if these need to be classes when they both don't have any instance states.
How about making them just
deocde
andencode
functions? That mirrors the structure ofstd/msgpack
Sure. I was trying to mirror the structure of TextEncoder
/TextDecoder
, but this other structure seems more common in the std.
Side note: TextDecoder
stores some chunk from the previous decode when stream
option is specified. Probably that is why it's implemented as a class
@BlackAsLight, could you please draft this PR and un-draft once ready for us to review?
Is there a way I can get the Sentry bot to update or create a new report on what lines are missing?
@BlackAsLight
Coverage diff of this PR should be visible in this page https://app.codecov.io/gh/denoland/std/pull/5909
CborSequenceDecoderStream CborByteDecodedStream CborTextDecodedStream CborArrayDecodedStream CborMapDecodedStream
There are mixed naming styles, FooDecoderStream
and FooDecodedStream
. Are these differences intentional?
We'd like to export a single API from a single file. Can you split files based on exported APIs
encode_cbor.ts
exports encodeCbor
encode_cbor_sequence.ts
exports encodeCborSequence
tag.ts
exports CborTag
sequence_encoder.ts
exports CborSequenceEncoderStream
byte_encoder_stream.ts
exports CborByteEncoderStream
text_encoder_stream.ts
exports CborTextEncoderStream
array_encoder_stream.ts
exports CborArrayEncoderStream
map_encoder_stream.ts
exports CborMapEncoderStream
decode_cbor.ts
exports decodeCbor
decode_cbor_sequence.ts
exports decodeCborSequence
sequence_decoder_stream.ts
exports CborSequenceDecoderStream
byte_decoded_stream.ts
exports CborByteDecodedStream
text_decoded_stream
exports CborTextDecodedStream
array_decoded_stream
exports CborArrayDecodedStream
map_decoded_stream
exports CborMapDecodedStream
@BlackAsLight
Coverage diff of this PR should be visible in this page https://app.codecov.io/gh/denoland/std/pull/5909
That page hasn't gotten updated in like 5 days now, which is why I asked.
CborSequenceDecoderStream CborByteDecodedStream CborTextDecodedStream CborArrayDecodedStream CborMapDecodedStream
There are mixed naming styles,
FooDecoderStream
andFooDecodedStream
. Are these differences intentional?
The difference in naming style is intentional. The "Encoder" and "Decoder" ones are TransformStreams that actually do the work of converting, while the "Decoded" ones are ReadableStreams that act as a simple wrapper so the user of the lib is able to know what type of chunks to expect.
I did explore the idea of having the "Decoded" ones also be TransformStreams and handling the logic of conversion, but the logic there seemed too complicated as you don't know how far to go until you've actually decoded it.
I also explored the idea of having the other "Encoder" ones (i.e. CborByteEncodedStream
) act as a mere wrapper for CborSequenceEncoderStream
, but that then seemed redundant if all you wanted to send for example a byte string, as more checks would essentially need to be done for no reason.
We'd like to export a single API from a single file. Can you split files based on exported APIs
* `encode_cbor.ts` exports `encodeCbor` * `encode_cbor_sequence.ts` exports `encodeCborSequence` * `tag.ts` exports `CborTag` * `sequence_encoder.ts` exports `CborSequenceEncoderStream` * `byte_encoder_stream.ts` exports `CborByteEncoderStream` * `text_encoder_stream.ts` exports `CborTextEncoderStream` * `array_encoder_stream.ts` exports `CborArrayEncoderStream` * `map_encoder_stream.ts` exports `CborMapEncoderStream` * `decode_cbor.ts` exports `decodeCbor` * `decode_cbor_sequence.ts` exports `decodeCborSequence` * `sequence_decoder_stream.ts` exports `CborSequenceDecoderStream` * `byte_decoded_stream.ts` exports `CborByteDecodedStream` * `text_decoded_stream` exports `CborTextDecodedStream` * `array_decoded_stream` exports `CborArrayDecodedStream` * `map_decoded_stream` exports `CborMapDecodedStream`
That is a lot of files, but I can do that.
I'll move the files *_decoded_stream.ts
to the private paths (_*_decoded_stream.ts
) and remove them from exports
entries in cbor/deno.json
as they are not intended to be used directly from the users. Let me know if you disagree with this change.
I'll move the files
*_decoded_stream.ts
to the private paths (_*_decoded_stream.ts
) and remove them fromexports
entries incbor/deno.json
as they are not intended to be used directly from the users. Let me know if you disagree with this change.
The user isn't meant to create instances of the decoded streams themselves, but they do need access to them to be able to figure out what type they have. For example with an entry instanceof ByteDecodedStream
.
Edit: maybe a Boolean function instead could be used instead by the user? isByteDecodedStream(entry)
. That's way there is no risk of incorrect use of the classes?
The user isn't meant to create instances of the decoded streams themselves, but they do need access to them to be able to figure out what type they have. For example with an entry instanceof ByteDecodedStream.
instanceof
check makes sense. Currently they are still exported from mod.ts
. Maybe it's also good to export them from relevant decoder
streams' endpoints.
@BlackAsLight
I added the exports of CborArrayDecodedStream
, CborByteDecodedStream
, CborMapDecodedStream
, CborTextDecodedStream
from cbor/sequence-decoder-stream
. What do you think?
@BlackAsLight
I added the exports of
CborArrayDecodedStream
,CborByteDecodedStream
,CborMapDecodedStream
,CborTextDecodedStream
fromcbor/sequence-decoder-stream
. What do you think?
Looks good to me
Closes https://github.com/denoland/std/issues/5479
This pull request introduces a CBOR implementation based off the RFC 8949 spec from scratch. It introduces functions like
encodeCbor
,encodeCborSequence
,decodeCbor
, anddecodeCborSequence
, and aCborTag
class to provide additional semantic information.It also introduces streaming versions called:
CborSequenceEncoderStream
CborByteEncoderStream
CborTextEncoderStream
CborArrayEncoderStream
CborMapEncoderStream
CborSequenceDecoderStream
CborByteDecodedStream
CborTextDecodedStream
CborArrayDecodedStream
CborMapDecodedStream
It should be noted the different naming convention used between the "encoder", "decoder" and "decoded". The "encoder" and "decoder" classes are TransformStreams, while the "decoded" classes are ReadableStreams and act merely as a way for the user to figure out what type they have.
Due to the way streams work, if one of the "decoded" streams are yielded then they'll need to either be entirely consumed or cancelled before the next value will be yielded. This should be noted when using things like
Array.fromAsync
. Such a function would work only if you can guarantee that no value yielded will be one of these "decoded" streams. If such a value is yield in such a function then it will hang indefinitely.Example 1
Example 2
Example 3