ludocode
commented
2 years ago Thanks, I'm glad you like MPack.
There isn't currently a standard schema for MessagePack. I have no plans to come up with one myself. There has been a bit of discussion about this on the MessagePack spec here: https://github.com/msgpack/msgpack/issues/202
One of the things I like about MessagePack is that it isn't defined by a schema. I think most users of MessagePack agree. Yes, it would be powerful if you could generate the write and expect code for your structures based on a schema, but I'm not a big fan of generated code. I definitely don't want to do a dynamic schema at runtime either (it sounds like this is what you were suggesting, an API for building the schema at runtime rather than a language or file format for generated code.) I'm also not a fan of reflection or annotations or other means of mapping structures for serialization. I've thought about this a lot and I don't see how to avoid all the things I dislike about Protocol Buffers and friends, or of the various object-relation mapping tools I've used. I would rather just write the serialization code manually.
There are plenty of schema-based formats you can use for data serialization if that's what you want: Protocol Buffers, Cap'N'Proto, Amazon Ion, etc. You can always use one of those instead.
I just found mpack and it's really nice!! There's one thing however that somehow puzzles me, and it is that when I write serialization code, I don't like to duplicate the hardcoded schema in the serializer and in the deserializer (duplicating the hardcoded schema calls for trouble -i.e: bugs- sooner or later, because there will always be one night when you are tired and you forget to keep them in sync).
So, while reading your docs, my mind was thinking: fine, but before using this, I need another API: one in which you define the node tree (the "hardcoded schema"), and then you have functions for setting values into the tree, and a function that just writes the whole tree. And then, another function which reads a messagepack, using your specified node tree just like the "Expect API" does: if the data being read doesn't conform to the node tree, errors or warnings are issued (or maybe custom user-callbacks for potentially fixing the errors when data conversion is possible).
The thing is that such API I'm thinking in, can be written on top of your existing API, so... just wondering: did you consider adding it at some point? Or do you have some reason for not writing it?