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

[Lennart Kolmodin]

Hey guys,
I didn't see this thread at first, thanks to Johan for bringing it to my
attention.

cereal is a fork of binary, and provided a incremental interface before
binary did.
It also has a few additional combinators like "isolate" and "label", which
is the reason why safecopy uses cereal instead of binary (at least I know
it uses "label").

As an experiment, I've wrapped the api of Data.ByteString.Builder and and
re-exported it as Data.Binary.Builder, but it turned out that performance
got worse. I have yet to look into why.
Once it all seems ok, binary will just wrap and re-export bytestrings
builder.
If you use binary or builder doesn't really matter, the basic APIs are very
similar. builder can offer some more options if you want to spend more time
in tuning for speed.

binary is also already in the HP, since it is bundled with GHC (GHC depends
on binary).
In other words, depending on binary should be future-proof.

On another note, binary-0.7 is out, get it while it's hot! :)

Lennart


2013/2/26 Johan Tibell <johan.tibell at gmail.com>

> On Mon, Feb 25, 2013 at 4:51 PM, Alexander Solla <alex.solla at gmail.com>wrote:
>
>> On Mon, Feb 25, 2013 at 11:59 AM, Johan Tibell <johan.tibell at gmail.com>wrote:
>>
>>>
>>> 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.
>>>
>>
>> Why not?  Those instances are useful.  Without instances defined in
>> binary/cereal, pretty much every Happstack (or, better said, every
>> ixset/acidstate/safecopy stack) user will have to have orphan instances.
>>
>
> I will have to give a bit more context to answer this one. After the
> binary package was created we've realized that it should really have been
> two packages:
>
>  * One package for serialization and deserialization of basic types, that
> have a well-defined serialization format even outside the package e.g.
> little and big endian integers, IEEE floats, etc. This package would
> correspond to Data.Binary.Get, Data.Binary.Builder, and Data.Binary.Put.
>
>  * One package that defines a particular binary format useful for
> serializing arbitrary Haskell values. This package would correspond to
> Data.Binary.
>
> For the latter we need to decide what guarantees we make. For example, is
> the format stable between releases? Is the format public (such that other
> libraries can parse the output of binary)? Right now these two questions
> are left unanswered in both binary and cereal, making those packages less
> useful.
>
> Before we answer those questions we don't want to 1) add
> more dependencies to binary and 2) define serialization formats that we
> might break in the next release.
>
> So perhaps once we've settled these issues we'll include instances for
> containers.
>
> Also, cereal has a generic instance.  Will the new binary?
>>
>
> That sounds reasonable. If someone sends a pull request Lennart or I will
> review and merge it.
>
> -- Johan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130301/6c0d3d29/attachment.htm>