Review: std.msgpack

Masahiro Nakagawa repeatedly at gmail.com
Fri Jun 18 18:36:18 PDT 2010


On Fri, 18 Jun 2010 23:05:45 +0900, Graham Fawcett <fawcett at uwindsor.ca>  
wrote:

> 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.

All right. I moved link to See_Also section in 1st paragraph.

> 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).

I like 'batteries included' approach(Python supports a diversity of  
modules).
Of course, quality is the most important thing.

I agree std.serializer.msgpack.

> 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.

D doesn't have CPAN-like system :'(


Masahiro


More information about the Digitalmars-d mailing list