I'm fine with the fact that Msgpack does not differentiate between binary data and text strings. Sure, it requires a schema, but if you're concerned with data size and parsing speed, you should choose an encoding appropriate for your task anyway.
The bigger problem is that Msgpack is advertised as being "like JSON, but fast and small." To me, that makes it sound like I can replace JSON messages with Msgpack messages and be done, and that's not at all the case, because I need to add a schema layer. I think the "like JSON" comparison is what is really causing this frustration with the format.
Hi, I wrote (with another guy) the objective-c wrapper.
You might be misinformed re schema layers, as msgpack does convert to and from a dictionary in much the same way that JSON does, keeping all your dictionary keys (which are strings) intact. In fact, we originally used it as a drop-in replacement for JSON.
As for the data vs string issue, it was designed originally to be as conveniently similar to JSON as possible - which is why you don't get back a dictionary full of NSData's which you then need to convert manually to NSString's; it does that automatically for you. This was a convenience vs correctness tradeoff. People who say it's wrong are quite right. They're very welcome to fork it, or submit patches with options to return raw NSData, or create a new wrapper - it wouldn't take a competent dev very long to re-write what we did.
Now, i've not used messagepack in quite a while - i've simply found that gzipped json is usually almost as good.
Thanks for replying. When I explored Msgpack, it was the Objective-C library that I tried using. Overall it was a great experience - nice work on the wrapper. I think you're right - I was trying to use Msgpack to do more than I could do with JSON (namely, to transmit NSData without having to stringify it). When I realized all the NSData objects were being automatically converted into strings when the data structure was inflated, I figured I'd need to prevent that behavior and do it on only certain keys (which would need to be specified somehow, hence my thought of a schema). Thanks for clarifying!
Comments
I'm fine with the fact that Msgpack does not differentiate between binary data and text strings. Sure, it requires a schema, but if you're concerned with data size and parsing speed, you should choose an encoding appropriate for your task anyway.
The bigger problem is that Msgpack is advertised as being "like JSON, but fast and small." To me, that makes it sound like I can replace JSON messages with Msgpack messages and be done, and that's not at all the case, because I need to add a schema layer. I think the "like JSON" comparison is what is really causing this frustration with the format.
Hi, I wrote (with another guy) the objective-c wrapper.
You might be misinformed re schema layers, as msgpack does convert to and from a dictionary in much the same way that JSON does, keeping all your dictionary keys (which are strings) intact. In fact, we originally used it as a drop-in replacement for JSON.
As for the data vs string issue, it was designed originally to be as conveniently similar to JSON as possible - which is why you don't get back a dictionary full of NSData's which you then need to convert manually to NSString's; it does that automatically for you. This was a convenience vs correctness tradeoff. People who say it's wrong are quite right. They're very welcome to fork it, or submit patches with options to return raw NSData, or create a new wrapper - it wouldn't take a competent dev very long to re-write what we did.
Now, i've not used messagepack in quite a while - i've simply found that gzipped json is usually almost as good.
Thanks for replying. When I explored Msgpack, it was the Objective-C library that I tried using. Overall it was a great experience - nice work on the wrapper. I think you're right - I was trying to use Msgpack to do more than I could do with JSON (namely, to transmit NSData without having to stringify it). When I realized all the NSData objects were being automatically converted into strings when the data structure was inflated, I figured I'd need to prevent that behavior and do it on only certain keys (which would need to be specified somehow, hence my thought of a schema). Thanks for clarifying!