search

TokTok / hs-msgpack-binary

Haskell implementation of MessagePack / msgpack.org
http://msgpack.org/
Other
16 stars 10 forks source link

Separate data-msgpack-types and serialisation implementations. #33

Closed iphydf closed 6 years ago

iphydf commented 7 years ago

We are currently tied to the binary package for serialisation. While very elegant, it may not be the best performing binary serialisation library. store seems to be faster. By separating the types and the specific serialiser, we can give the user a choice, and we can provide at least two implementations: one correct one (the existing one) and one fast one. We can then do random quickcheck-style equivalence testing between the two to make sure the fast one is also correct.

SX91 commented 7 years ago

Also we need to extend (well, actually (re)write) documentation to point that data-msgpack is required for encoding/decoding (with binary) only, for MessagePack instances data-msgpack-types (or data-msgpack-class?) would be enough.

SX91 commented 7 years ago

@iphydf if you could make a separate repo for types (or class, or object, whatever), I'd move all types related code there as a PR.

iphydf commented 7 years ago

Done: https://github.com/TokTok/hs-msgpack-types

SX91 commented 7 years ago

Do we need a re-export modules like Data.MessagePack.Object etc? I've put all types modules to Data.MessagePack.Types.*.

iphydf commented 7 years ago

I don't know. So far I've been limiting the number of exposed modules, which gives some freedom to restructure and rearrange data and code. Perhaps a single Data.MessagePack.Types module re-exporting those would be good as the public API? Currently (in master) we don't expose .Object directly.

iphydf commented 6 years ago

Done in #43.