141–150 of 162 posts
This text vs. binary discussion is pretty high level. HTTP/2.0 has a mux layer (let's temporarily put aside whether that's a good idea) and some of the payloads have to be binary (e.g. JPEGs). There are basically three ways you can do this: A. base64 everything. Obviously this has high overhead. B. Escaping (aka byte stuffing). This is somewhat slow to escape and unescape, the overhead is variable (in rare cases 100%…
Earlier quoted context omitted.
It's not just the binary. It's that HTTP 2 is hugely more complex. Excessive complexity is a general engineering smell. It can't be all that difficult to implement a protocol for applying a few verbs to URIs. Complex + non-discoverable = bad engineering
HTTP is already painfully complex to implement correctly. It's also a terribly wasteful and poor engineered protocol for anything other than fetching documents.
The fact is, on the application layer, text based protocols wiped the floor with binary protocols. The answer is in the little details, which everyone knows is where the devil spends its time. They are not easier to implement, because they're more difficult to debug (and because text parsers are, let's be honest, a solved problem); they are not as readable, because debug tooling is never perfectly implemented and never ever present in every system; they are more efficient, but at this layer the efficiency does not pay off (i.e. the size of the HTTP header leading that 5MB image does not really matter).
One of the comments here pulled a comparison I did not remember any more: SS7 vs SIP. Go and have a look at both protocols. They are both mature, so you don't really need to wait for the fantastic debug tooling to appear. Study both ecosystems and then form your opinion on binary vs text application protocols.
Earlier quoted context omitted.
The tools might get written . But they won't be installed on those routers, remote servers you're not getting to install stuff on and all kinds of other places where people who work with networks frequently want to be able to talk protocols from. It's largely irrelevant to me if there are tools out the wazoo to work with some binary protocol if I'm unable to run that tool everywhere. And there's a huge range between…
This is just scaremongering. Installing the command line LDAP tools (which is a horrendous binary protocol) is no harder than installing netcat or tcpdunp.
For some reason, I feel as though the people in this thread against text-based protocols have never used telnet to inspect or debug an HTTP request/response. Or used telnet to help develop a client for something like memcached. The ease of discoverability of a protocol should not be underrated.
I've written a couple parsers and stacks for SIP, a HTTP-derived protocol. The text-based aspect isn't bad in and of itself. It's the crazy moronic rules and pointlessly flexible syntax that makes it bad. It's the fact that "text-based" is often taken to mean "should allow humans to be flexible in writing it", instead of "uses ASCII". Oh, and UTF8 if you're lucky. If you dare want a non-ASCII value that needs to go i…
Earlier quoted context omitted.
and lots of experiments, new websites and happy users appeared because HTML has been accepted leniently
would those experimental users have given up right when the browser reported "Missing tag"?
Earlier quoted context omitted.
and lots of experiments, new websites and happy users appeared because HTML has been accepted leniently
would those experimental users have given up right when the browser reported "Missing tag"?
So this was entirely by design and probably not all that difficult to implement. That it might not be appealing to some I can understand. I suspect the creators of SGML had very different concerns.
I like that HTML has a very humane interface.
Earlier quoted context omitted.
HTTP is already painfully complex to implement correctly. It's also a terribly wasteful and poor engineered protocol for anything other than fetching documents.
Those who do not know History are doomed to repeat it. Back in the day of the OSI stack, the telecom guys were huge fans of binary protocols. The arguments were exactly those described here on HN: they're easier to implement; with the right tooling, they're just as readable; they're more efficient. The fact is, on the application layer, text based protocols wiped the floor with binary protocols. The answer is in the…
Do you remember the OSI binary protocols as designed back in the day?
ASN.1 as far as the eye could see. OIDs. MIBs. Loosely defined extensibility. Terrible, complex protocol designs.
This had nothing to do with the protocols being binary or text; the protocols themselves were painfully complex, making it difficult and frustrating to write a working implementation, much less a complete and interoperating implementations.
> ... at this layer the efficiency does not pay off (i.e. the size of the HTTP header leading that 5MB image does not really matter).
"I don't care about RTT time, the lack of bidirectional communication, and the inability to inline binary data in the protocol stream" ... said no mobile/wireless/desktop developer, ever.
> One of the comments here pulled a comparison I did not remember any more: SS7 vs SIP.
I've implemented SIP. It was a massive hassle because it was text-based and annoying and difficult to parse. The available SIP libraries tend to be buggy and incomplete, and people actually pay for workable SIP stacks. I'd rather not look at SIP ever again.
That isn't to say SS7 is better, it doesn't appear to be. As far as I can tell, that's because it was badly designed, not because of a flaw inherent in using binary encodings.
Earlier quoted context omitted.
This is just scaremongering. Installing the command line LDAP tools (which is a horrendous binary protocol) is no harder than installing netcat or tcpdunp.
It might sound like scaremongering to you. To me, the reality is every network I've worked on have had devices that I can not install and run arbitrary code on. Most non roll-your-own routers for example does not give you a shell where you can install arbitrary applications. But many of them do have tools like ability to telnet to help diagnose problems.
For that matter, how do you perform more than cursory debugging of HTTP services? Do you seriously sit there and carefully type out HTTP 1.1 compliant requests, along with requisite headers and maybe even cookies? Does that actually work for debugging complex issues, and does it really differ that substantially from the debugging one performs to see if a binary protocol service is up and accepting requests?
For some reason, I feel as though the people in this thread against text-based protocols have never used telnet to inspect or debug an HTTP request/response. Or used telnet to help develop a client for something like memcached. The ease of discoverability of a protocol should not be underrated.
I agree. Much of that attitude is also pompous. Engineering should be about taking complex things and making them simple and easy (the best engineers do this), on the other hand you have engineers that try to add complexity because they understand something and over engineer it to obscure it on some premature optimization or cool factor. Taking something simple and making it more complex is the epitome of bad enginee…
Earlier quoted context omitted.
> * but human-readability is very useful.* For who, how often and when exactly? As far as I have understood, we are doing something wrong if we have to deal with debugging protocols which implement an abstraction, rather than just let the abstraction do it's job. This is like saying that "Well for programmers x86 assembly instruction mnemonics are useful compared to machine code bytes!", to which one could say that f…
> For who, how often and when exactly? As far as I have understood, we are doing something wrong if we have to deal with debugging protocols which implement an abstraction, rather than just let the abstraction do it's job. Any time you're debugging "one layer above" and you're in Sherlock Holmes territory (i.e. the problem seems impossible, so one of your basic assumptions must be incorrect) you have to check stuff.…
Instead of ACKNOWLEDGE you say ACK or mere A. Instead of REQUEST PAGE FROM , you say RPF and so on. This is my main point of hatred towards "human readable formats", because they waste bytes for no reason.
I can run the water for as long as I want without absolutely no consequences for me, but why would I do it if I can avoid it? Why would I not save resources whenever I can, even though I don't need to do it? It's more a philosophical question, to which I would answer with "save anything you can, whenever you can and make no waste.". Very simple.