Support RFC-8742 - Concise Binary Object Representation (CBOR) Sequences - in a performant way without catching exceptions

[ChristophLindemann]

It would be nice to support RFC-8742 (Concise Binary Object Representation (CBOR) Sequences) in a sane and performant way ,

instead of the naive and non-performant way, which was copy pasted from my workaround in #67 and dumped into the codebase (#104).

As I wrote in the original issue (#67):

I think it can be reasonable easy be supported in CborReader by using ReadOnlySequence / SequenceReader / PipeReader.

Another benefit would be, if you have very large CBOR objects, using something like the PipeReader would enable you to -not- read the complete CBOR stream into memory before decoding.

[ChristophLindemann]

Oh, and hopefully, this time I will have time to do a PR for you.

[mcatanzariti]

Your technical input is appreciated, but please try to keep the tone respectful.

I'm open to a PR if you'd like to help improve this.

[ChristophLindemann]

Sorry for the tone. I was frustrated that someone tock my hack/workaround, and put it into the codebase as "solution". In hindsight, I should never had posted the original workaround.

[ChristophLindemann]

@mcatanzariti to really get this going for streaming, I would need to refactor the core CborReader class to use a PipeReader, and the read methods like ReadUInt64 would need to be TryReadUInt64, so they would not fail when not enough bytes are available in the stream to complete the item.

What are your thoughts about that?

[mcatanzariti]

Hi @ChristophLindemann,

To be honest, I'm not particularly fond of PipeReader architecture proposed by Microsoft a few years ago, it brings a lot of complexity in the implementation.

But it if you think it's the best solution for streaming, I'm curious to see your proposal!

Michaël

[ChristophLindemann]

@mcatanzariti thank you for the feedback. Anything you prefer instead?

The problem is, that the current implementation expects the stream or sequence to be complete (or at least for the next item). But when reading from network, serial port or similar, the this might not be the case, some bytes might still need to be transferred, and CborReader.ReadXXX() would not have enough bytes and throw. So we would need TryReadXXX methods.
Then we could implement the local Cbor.ReadNextItemAsync.TryReadItem() without catch but with a ICborConverter.TryRead call instead.

Actually, I would not need to introduce PipeReader into the code in the CborReader. I would only need to add TryRead kind of overloads to the reader and converters.

Also, I still have to think on how to tackle the Indefinite-length types. For those, a iterator would make sense. You might not want to read the whole content into memory. But the Cbor facade should probably not support that use-case. This can be supported by using the CborReader class (if it has TryReadXXX methods).

[mcatanzariti]

yes, you're right the TryRead methods seems to be the right solution.