4 ms·

I think your view, while warranted, is very web programming centric. MessagePack was initially developed for RPC. That might explain some of the "oddities" when

by kiyoto 14y ago

I think your view, while warranted, is very web programming centric. MessagePack was initially developed for RPC. That might explain some of the "oddities" when viewed as a drop-in, space-efficient replacement for JSON.

prodigal_erik 14y ago
msgpack.org probably shouldn't be promoting it as a "perfect replacement", when valid messages which have no JSON equivalent have already been seen in practice. At best it's a superset, and if none of the implementations can confine you to a JSON-compatible subset (no byte strings, no int64, no non-string keys) which assures interop, that's a problem. Mostly I wish people would agree on a schema and use ASN.1 PER, rather than choosing from the ever-growing list of binary type-length-value formats which put a redundant copy of the schema on the wire in every message (making them neither small nor readable). I've never had occasion to do anything useful with a message whose format wasn't already known when I wrote the code.
stock_toaster 14y ago
> I think your view, while warranted, is very web programming centric FWIW, I do very little "web work" (by which I assume you mean front-end?). Instead it is mostly api endpoints for mobile and server-to-server backend messaging. Lots of http transport stuff. If I were doing rpc, I would either not (and use a restful or type-2 api), or use something like protobuf or thrift. Msgpack just doesn't seem, to me, as a really great fit for anything in particular.
- kiyoto 14y ago
  I don't mean frontend but anything related to web services, really. "Lots of http transport stuff" is still "web programming" (for me, at least). >Msgpack just doesn't seem, to me, as a really great fit for anything in particular. Pinterest disagrees: http://engineering.pinterest.com/posts/2012/memcache-games/ http://engineering.pinterest.com/posts/2012/memcache-games/ To give you some context, frsyuki developed MessagePack originally for RPC (he was building a distributed key-value store in college) and made a conscious decision not to add a string type for maximal cross-language compatibility. Like a lot of other technology, MessagePack has outlived its original purpose, and there is a lot of demand now for it to support the (utf-8) string type, not just byte array.
  - stock_toaster 14y ago
    > "Lots of http transport stuff" is still "web programming" (for me, at least). Web programming to me sounds like javascript and css. A the very least something to do with html output at some point. Oh well. > Pinterest disagrees: http://engineering.pinterest.com/posts/2012/memcache-games/ I didn't see any reference in that post to them trying compression. It would have been an interesting comparison. Good data point on usefulness though. Thanks for that.

by kiyoto 14y ago

prodigal_erik 14y ago

msgpack.org probably shouldn't be promoting it as a "perfect replacement", when valid messages which have no JSON equivalent have already been seen in practice. At best it's a superset, and if none of the implementations can confine you to a JSON-compatible subset (no byte strings, no int64, no non-string keys) which assures interop, that's a problem. Mostly I wish people would agree on a schema and use ASN.1 PER, rather than choosing from the ever-growing list of binary type-length-value formats which put a redundant copy of the schema on the wire in every message (making them neither small nor readable). I've never had occasion to do anything useful with a message whose format wasn't already known when I wrote the code.

stock_toaster 14y ago

> I think your view, while warranted, is very web programming centric FWIW, I do very little "web work" (by which I assume you mean front-end?). Instead it is mostly api endpoints for mobile and server-to-server backend messaging. Lots of http transport stuff. If I were doing rpc, I would either not (and use a restful or type-2 api), or use something like protobuf or thrift. Msgpack just doesn't seem, to me, as a really great fit for anything in particular.

kiyoto 14y ago
I don't mean frontend but anything related to web services, really. "Lots of http transport stuff" is still "web programming" (for me, at least). >Msgpack just doesn't seem, to me, as a really great fit for anything in particular. Pinterest disagrees: http://engineering.pinterest.com/posts/2012/memcache-games/ http://engineering.pinterest.com/posts/2012/memcache-games/ To give you some context, frsyuki developed MessagePack originally for RPC (he was building a distributed key-value store in college) and made a conscious decision not to add a string type for maximal cross-language compatibility. Like a lot of other technology, MessagePack has outlived its original purpose, and there is a lot of demand now for it to support the (utf-8) string type, not just byte array.
- stock_toaster 14y ago
  > "Lots of http transport stuff" is still "web programming" (for me, at least). Web programming to me sounds like javascript and css. A the very least something to do with html output at some point. Oh well. > Pinterest disagrees: http://engineering.pinterest.com/posts/2012/memcache-games/ I didn't see any reference in that post to them trying compression. It would have been an interesting comparison. Good data point on usefulness though. Thanks for that.