Non-string map keys

[ecorm]

Perhaps I've missed something in the documentation, but it's not clear whether non-string map keys are supported via the cursor interface when decoding CBOR or Msgpack. The same goes with basic_msgpack_encoder and basic_cbor_encoder for writing maps with non-string keys. Can someone please clarify?

I don't actually need non-string key support right now; I was just curious if it was indeed supported.

[danielaparker]

It's supported at the lowest levels. At the lowest levels, keys can be any value, including object and array. Specifically, the push parsers basic_cbor_parser and basic_msgpack_parser write parse events to a basic_json_visitor2, which receives key-value pairs as a pair of values rather than a key and a value. Higher levels, though, use an adaptor to adapt the basic_json_visitor2 to a basic_json_visitor for parsing. The adaptor receives object members as a pair of values, serializing the first value to a string, and outputs them as a string key and a value. So currently, if you needed the non-stringified key, you would need to work at the level of basic_json_visitor2.

Currently our pull readers, basic_cbor_cursor and basic_msgpack_cursor, use a basic_staj_cursor, which receives events though a basic_json_visitor, and thus can only report stringified keys. It would be pretty straightforward though to introduce a basic_staj_cursor2, which receives events through a basic_json_visitor2, and a basic_cbor_cursor2 and basic_msgpack_cursor2, which report object members as a pair of values, one following the other. My main difficulty is that I would like to come up with more inspired names than basic_json_visitor2 , basic_staj_cursor2, etc.!

basic_cbor_encoder and basic_msgpack_encoder implement basic_json_visitor, and hence support receiving object members as a string key followed by a value. However, I believe it would work to instead send two values in succession. Here, key is just another way of sending a string value to the encoder. To make this more explicit, I think these two encoders could implement both basic_json_visitor and basic_json_visitor2, the former is the same as the latter except for the additional key and do_key functions.

[ecorm]

It turns out I need basic_foo_parser because I want to be able to reset and reuse the parsing machinery without having to instantiate it for every inbound message in my networking library. basic_foo_cursor seems to be single use only.

Unfortunately, basic_foo_encoder seems to be single-use, with no way to bind a new Sink to it. I suppose I could write my own sink class that allows it to be re-bound to a new destination buffer, but this assumes that basic_foo_encoder is able to encode more than one root-level document.