On Monday, February 25, 2013 at 2:59 PM, Johan Tibell wrote:
> On Mon, Feb 25, 2013 at 4:30 AM, Nicolas Trangez <nico...@incubaid.com > (mailto:nico...@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@haskell.org (mailto:Haskell-Cafe@haskell.org) > http://www.haskell.org/mailman/listinfo/haskell-cafe > >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
