Currently you can only encode, not decode.

When writing a value that is part of a U16, U32 etc, they value might possibly be represented in a smaller value. Add methods/functionality to allow this to happen.

Note, this should be a separate method so any additional processing overhead is not incurred if speed of encoding is valued over compactness of representation.

This might require changes to decoding as well to take a value that was encoded as a U8 but we are expecting as a U16 to get it back as a U16.

Currently the examples directory only has a placeholder.

pony-msgpack doesn't currently support the map type family as I'm figuring out how to write a good type safe API for it.

see: https://github.com/msgpack/msgpack/blob/master/spec.md

pony-msgpack doesn't currently support the array type family as I'm figuring out how to write a good type safe API for it.

see: https://github.com/msgpack/msgpack/blob/master/spec.md

pony-msgpack doesn't currently support adding extension types.

see: https://github.com/msgpack/msgpack/blob/master/spec.md

Examples on how to use as part of top level MessagePack package documentation.

Particular emphasis should be placed on using Map and Array correctly.

The ext, str, bin decoding methods both will decode any str/ext type. This is good for developer convenience, however, the embedded if statements to find the correct type is going be slower than being able to call something like ext_16.

Support for decoding

• fixext_1
• fixext_2
• fixext_4
• fixext_8
• fixext_16
• ext_8
• ext_16
• ext_32
• bin_8
• bin_16
• bin_32
• str_8
• str_16
• str_32

should be added for when performance is of maximum importance.

both encoding and decoding.

see: https://github.com/msgpack/msgpack/blob/master/spec.md#timestamp-extension-type

The decoder assumes that all data is available. Trying to use a streaming use case where you can read the byte for a type but then the full data for that type is not yet available would corrupt the stream and the reader.

With the addition of the timestamp support from @rkallos, it's a good time to do a 0.3.0 release. I think as part of that, I'll add a release process doc and a bit of scripting.