Review: std.msgpack

[Graham Fawcett]

On Thu, 17 Jun 2010 21:29:50 -0700, Andrei Alexandrescu wrote:

> There's one larger submission that needs review - Masahiro Nakagawa's
> std.msgpack. I think it would be great if this community established a
> review process. 

+1!

> To do so, we should abstract away starting from at least
> one review :o). Here's Masahiro's work:
> 
> code: https://dl.dropbox.com/u/374829/std/msgpack.d doc: 
> https://dl.dropbox.com/u/374829/std/msgpack.html zip: 
> https://dl.dropbox.com/u/374829/std_msgpack.zip (archives code and doc)
> 
> Feel free to comment here.

Nice!

The docs should link to the MessagePack Format Spec page in the first
paragraph. I had not known that MessagePack was an existing binary
serialization format.

http://redmine.msgpack.org/projects/msgpack/wiki/FormatSpec

I was going to complain that this module didn't handle D-specific
types like Variants, but now I see that this is out of scope.

Just curious, why have MessagePack support in Phobos, instead of
Packed Encoding Rules, BERT, BSON, Protocol Buffers, etc.? Not that
this isn't a very useful module, but I'm curious about why this
particular binary encoding.

If it's a 'batteries included' thing ("let's put as many useful
modules as possible in the stdlib"), then maybe a dotted name like
'std.serializer.msgpack' might be better, to give a proper home for
'std.serializer.per', etc.? I'm not sure this deserves the same 'top
level billing' as, say, std.stdio or std.range; and eventually the
toplevel namespace will be very cluttered (c.f. Python's stdlib).

In a perfect world, I would see this as an excellent member of a
CPAN-like system for D, rather than a stdlib module. Since that
doesn't exist yet, +1, but with a nested module name.

Best, 
Graham