Right now, there are lots of complications in designing this library, at least if I want a nice API. I have lots and lots of type definitions to encode the various constructs of the protocol I'm working with. New versions could make arbitrary changes: add or remove a field to a record, change the type of a record field, add or remove one of several possible cases (which I encode with sum types), and so on. It's not at all clear to me yet how I should factor my type definitions, and/or use other features such as polymorphic types, type classes, etc. But I guess this is a different thread.
On Wed, May 12, 2010 at 4:35 PM, Stephen Blackheath [to Haskell-Beginners]
<mutilating.cauliflowers.stephen@blacksapphire.com> wrote:
Ashish,
I've been using XML picklers for serialization, which you might want to
consider if you can handle a little extra CPU/data cost. I'm the author
of hexpat-pickle, so this is a plug for my package. I lifted the idea
wholesale from the HXT package.
Handling changes in protocol version is really easy. I've been doing a
lot of
xpSomething = new `xpTryCatch` old
where
new = ...
old = ...
If the new encoding fails to parse, it tries the old one, and on
transmission it uses the new one. I find it very quick and convenient
to bang out a new pickler now that I'm familiar with it. You write your
pickler and your unpickler with the same code - it works well.
I am also working on hexpat-iteratee which is a lot more socket friendly
since it doesn't use Haskell's lazy I/O. The learning curve increases a
little bit with doing it that way, though.
Steve
On 13/05/10 05:15, Ashish Agarwal wrote:
> Thanks for all the advice. It seems I should avoid making my types
> instances of Binary. In fact, this relates to another design issue I've
> been grappling with, supporting multiple versions of the protocol.
> Probably I'll need something like, putProtVersion1, putProtVersion2,
> etc. Or something along this line.