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

[Ozgun Ataman]

On Monday, February 25, 2013 at 2:59 PM, Johan Tibell wrote:

> On Mon, Feb 25, 2013 at 4:30 AM, Nicolas Trangez <nicolas at incubaid.com (mailto: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.
As a minor side note: Just wanted to point out that safecopy (http://hackage.haskell.org/package/safecopy) provides a nice migration framework for production use cases and is based on cereal. Migration becomes an issue in production sooner or later, and I think safecopy is a nice alternative to the approach Google's protocol buffers takes (for example). For eventual unification on binary, it may be a good idea to port it (and other useful libs that build on cereal) as well. 
>  
> > - 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
>  
> 
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org (mailto:Haskell-Cafe at haskell.org)
> http://www.haskell.org/mailman/listinfo/haskell-cafe
> 
> 


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