[Haskell-cafe] The state of binary (de)serialization

[Johan Tibell]

On Mon, Feb 25, 2013 at 4:30 AM, Nicolas Trangez <nicolas at incubaid.com>wrote:

> - cereal supports chunk-based 'partial' parsing (runGetPartial). It
> looks like support for this is introduced in recent versions of 'binary'
> as well (runGetIncremental)
>

Yes. Binary now support an incremental interface. We intend to make sure
binary has all the same functionality as cereal. We'd like to move away
from having two packages if possible and since binary has the larger
installed user base we're trying to make that the go-to package.


> - cereal can output a strict bytestring (runPut) or a lazy one
> (runPutLazy), whilst binary only outputs lazy ones (runPut)
>

The lazy one is more general and you can use toStrict (from bytestring) to
get a strict ByteString from a lazy one, without loss of performance.


> - Next to binary and cereal, there's bytestring's Builder interface for
> serialization, and Simon Meier's "blaze-binary" prototype
>

Simon's builder (originally developed in blaze-binary) has been merged into
the bytestring package. In the future binary will just re-export that
builder.


> There are some blog posts and comments out there about merging cereal
> and binary, is this what's the goal/going on (cfr runGetIncremental)?
>

It's most definitely the goal and it's basically done. The only thing I
don't think we'll adopt from cereal is the instances from container types.


> In my use-case I think using Builder instead of binary/cereal's PutM
> monad shouldn't be a major problem. Is this advisable performance-wise?
>

You can go ahead and use the builder directly if you like.


> Overall: what's the advised future-proof strategy of handling binary
> (de)serialization?


Use binary or the builder from bytestring whenever you can. Since the
builder in bytestring was recently added you might have to fall back to
blaze-builder if you believe your users can't rely on the latest version of
bytestring.

-- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130225/db6f6943/attachment.htm>