2016-02-10 1:33 GMT+03:00 Bram Moolenaar <[email protected]>: > > Alejandro Exojo wrote: > >> > > You can consider CBOR as well, if you want something well standarized: >> > > >> > > http://tools.ietf.org/html/rfc7049 >> > > >> > > There are some similarities with msgpack, but IIRC it has some >> > > additions. Here is a library, in case you want to consider adding it >> > > or playing with it: >> > > >> > > https://github.com/01org/tinycbor >> > >> > I don't like binary formats. >> >> Then you confuse me more. Isn't Protocol Buffers binary? > > Protocol buffers is a specification format. There is an implementation > with binary messages. Messages are quite efficient, but require bit > manipulation for encoding and decoding. Doesn't work so well in some > languages, e.g. JavaScript. And it's impossible to read the message > without a tool that knows the format being encoded. Bit of a problem if > you're single stepping through code. > > The JS encoding is nearly as efficient and is (more or less) readable. > Encoding/decoding performance isn't much different in most languages, > it's much faster in JavaScript (so long as you trust eval()). > >> Also, given that the goal is RPC, and not just a format, note that both the >> old and the new guys of Protocol Buffers are considering newer approaches: >> >> https://capnproto.org/news/2014-06-17-capnproto-flatbuffers-sbe.html > > Don't know it. At least see some statements that aren't exactly true. > Seems very similar to protocol buffers. > >> > > > Also keep in mind that when you want to stick to the JSON standard >> > > > (well, one of them), >> > > >> > > Is there more than one JSON standard? The standard might have flaws, >> > > and even more so the implementations, but there is supposed to be only >> > > one. >> > >> > https://tools.ietf.org/html/rfc4627 >> > https://tools.ietf.org/html/rfc7159.html >> > http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf >> > >> > There was also rfc7158 but it was discarded. >> >> One RFC obsoltes the other. The more up to date RFC is more recent than the >> ECMA paper, but I don't see any significant difference, specially an >> incompatible one. It just says: >> >> RFC 4627 was written by Douglas Crockford. This document was >> constructed by making a relatively small number of changes to that >> document; thus, the vast majority of the text here is his. >> >> I see some clarification with respect to encoding, actually. > > Perhaps I should write my own standard and state that this obsoletes the > others, since mine is of course going to be better. (hint: obsolete > doesn't mean unused). > >> > I already pointed out some flaws. Another one is that it should only >> > support utf-8 and nothing else to simplify encoders/decoders. >> >> The RFC doesn't say so. But yes, if you put an invalid text inside a >> text type, you are going to get awkward results. A string type in some >> languages or libraries just doesn't support broken Unicode. >> >> If the definition of a text type is what is specified by Unicode (why would >> you choose a different specification of something as complex as that?), you >> need to be strict, and use a byte array if you need something more liberal. > > Yep. And then you can also support NULs. But don't confuse syntax and > semantics, you can encode any binary byte sequence into a JSON string.
How exactly? Whatever you choose this is going to either make resulting format less efficient or less portable. Example of less portable: surrogateescape scheme where byte 0xFF is encoded as U+DCFF (resulting in `"\uDCFF"` JSON string because literal U+DCFF is not a valid UTF-8 string) without another character from the surrogate pair. Works fine in Python, but it does not have to. “Less portable” variant may turn into “less efficient” or “not working at all” with some implementations. Example of less efficient: quoted-printable encoding. Does not matter what exactly you will choose, this thing will require all strings to be additionally filtered on the other side, without custom JSON parser this may make parsing+postprocessing your JSON even a magnitude or more slower: in cases like Python where json module is written in C, but postprocessor will be written in Python. There is a middle option though: use channel types “json-surrogateescape” and “json-quoted-printable”, it would be up to server what exactly to choose. Though I would have chosen a binary format in any case (but not msgpack like in Neovim unless you are actually going to be compatible, protocol buffers binary messages look better). > > -- > hundred-and-one symptoms of being an internet addict: > 204. You're being audited because you mailed your tax return to the IRC. > > /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ > /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ > \\\ an exciting new programming language -- http://www.Zimbu.org /// > \\\ help me help AIDS victims -- http://ICCF-Holland.org /// > > -- > -- > You received this message from the "vim_dev" maillist. > Do not top-post! Type your reply below the text you are replying to. > For more information, visit http://www.vim.org/maillist.php > > --- > You received this message because you are subscribed to the Google Groups > "vim_dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
