Support no-op ("N") in the decoder.

[chmarr]

I believe supporting the no-op in the decoder (not the encoder) to be important.

I agree that in encoding/sending it should be in a lower layer. But in the decoder/receiver, the lower layer cannot tell which "N"s are a no-op versus part of a string or binary-encoded value without additional information or fully decoding the stream, which is the decoder's job.

(Also, this would also let me use "N" as a prefix to distinguish JSON and UBJSON-encoded data. :) )

[vtermanis]

Reading here and also in the original spec, No-Op can only occur as an element within a container which means:

• Inserting No-Op at the transmission end requires knowledge of the state of encoding (so couldn't be at a lower level I think)
• Detecting UBJSON by starting No-Op is not possible. This should probably be the responsibility of a header

What I meant by "should be done by lower layer" is not using the No-Op at all but a different mechanism (e.g. TCP keep-alive or some such). Since the encoder in this module is not iterative, it's not possible to perform what is given as an example in the ubjson.org document: That is to post No-Op values in the middle of encoding a container type.

However, for compatibility with other encoders which do insert No-Op values, I'll consider making the decoder handle them.

[vtermanis]

@chmarr, have a look at the dev-contrib branch - does this address your use-case? (Please note the comments in the README regarding No-Op placement.)

[vtermanis]

Closing due to lack of feedback of feedback from original issue raiser. (Functionality will be included in next release.)