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
