On Fri, 18 Jun 2010 23:05:45 +0900, Graham Fawcett <fawc...@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
