On Fri, 18 Jun 2010 23:47:38 +0900, Robert Jacques <sandf...@jhu.edu>
wrote:
Second, a lot of the design and examples are very similar to the MsgPack
reference implementations, which are all Apache licensed. Since some of
these design decisions seem to not be 'D'-ish (more on that later) this
raises questions on just how clean room the implementation was.
The author of MessagePack allows this module to apply Boost Software
License.
Third, there's a lot of things that shouldn't be in the final module.
-Should be removed:
SimpleBuffer, VRefBuffer/vRefBuffer,
-Redundant with other parts of phobos:
BinaryFileWriter => LockingTextWriter, mp_Type/mp_Object/mp_KeyValue =>
std.variant
BinaryFileWriter removed.
mp_Object is based on std.json.JSONValue.
Variant can't have mp_pack method.
Hmm..., I check Variant again.
-Should be moved elsewhere
DeflateFilter/deflateFilter => zip/zlib
I agree.
Forth, msgpack was designed to be a simple, wire level encoding of some
higher structure. As opposed to JSON or XML, you are not going to be
modifying it dynamically. The very concept that it would use buffers
internally, particularly the existence of the "zero-copy" buffer,
baffles me. (Not to mention it leaves one open to aliasing bugs.)
MsgPack has to decorate every single type it stores, so there is nothing
"zero-copy" about it. To that end, I think MsgPack/MsgUnPack should wrap
an input or output range as appropriate and be able to be used by a
general serialization library such as Orange.
If Phobos has std.serializer like Orange(or Doost.Serialization?),
I will implement MsgPackArchive.
But general serializer usually is low-performance and lacks some features.
So when user wants performance, user will use Packer and Unpacker directly.
Other little things,
-Why isn't nil mapped to null?
Where?
-Why isn't there any big warnings about serializing cycles?
Oops. Current implementation can't deal with a circular reference.
I added NOTE section to Packer's comment.
Masahiro
