The site crashes my phone browser.
Dolphin Mini.
HTC Wildfire.
Android 2.2.2
The 7-bit Internet
31–40 of 162 posts
Re: The 7-bit Internet
#32The original idea behind the web was a publishing platform that, like a classic car, would be easy to explore, maintain and develop. The new vision is the application. Whether it's on a phone, or running as a web site, these are not publishing so much as services. Perhaps it's time to fork protocols: one for publishing, one for interactive applications.
This has been on my mind, too, for a long time. Many applications don't fit the semantic framework of the WWW anyway; why not call it a day and fork it? This way the web app crowd will be able to do their somethingJS magic without worrying about what the WWW was meant to be, and the people who use WWW for publishing can get a sane platform back on track.
Re: The 7-bit Internet
#33For 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.
Writing new protocol modules for tcpdump isn't difficult.
Re: The 7-bit Internet
#34While I agree that it sucks to lose text based protocols, we already have an underlying protocol that is completely binary in nature and requires tools to look at it (TCP). Same can be said for IP. We've survived a long time with those technologies and we have some awesome tools for working with them. While it's not as easy as ascii based protocols, it's more space efficient, which I'm fine with.
But one of the beautiful features of TCP is that it has the properties necessary to treat it as a text stream -- you can build text-based protocols on top of it. Since troubleshooting an application-level protocol seldom requires you to delve into the TCP-level, it works very well in practice. The HTTP 2.0 draft not only makes the application-level protocol binary, but it eschews the simpler stream metaphor in favor of replicating a bunch of that TCP-level complexity in the higher layer.
There are reasons for all of this, of course -- it's not being proposed on a lark. But it does have a very real complexity cost.
Re: The 7-bit Internet
#35Oh sure, let's keep buffer bugs, waste tons of bandwidth and storage, burn millions of CPU hours in parsing computer-generated text, completely ban encryption and screw it for all non-en_US-speakers so that it could be debugged via misuse of a protocol from 1983 that no one sane uses.
I watched simple text-based internet protocols eat the efficient, ASN.1 OSI protocols for breakfast. From the OSI side of the fence. You can talk about efficiency until you're blue in the face, but human-readability is very useful. I used to be able to pretty much parse a hexdump of an X.400 P1 PDU by eye (certainly if I could reformat in a text editor), but even today I found it useful to eyeball a recalcitrant prog…
> * 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 for an average programmer that makes no sense.
I didn't quite care about stuff like this until I got introduced to information theory and really started thinking about what it means to send and receive information. The amount of totally unnecessary waste is astounding.
Re: The 7-bit Internet
#36Oh sure, let's keep buffer bugs, waste tons of bandwidth and storage, burn millions of CPU hours in parsing computer-generated text, completely ban encryption and screw it for all non-en_US-speakers so that it could be debugged via misuse of a protocol from 1983 that no one sane uses.
I agree. HTTP with chunking is already way beyond the human-emulatable-via-telnet threshold.
Re: The 7-bit Internet
#37I don't understand why SPDY / HTTP 2.0 is being framed as "fitting the needs of a few major players". Google is not the only one who benefits from reduced latency, fast page loads, efficient use of SSL sessions, and server pushed resources. If anything, the people who benefit the most are those who _can't_ afford massive forward deployed CDN networks, large servers, and fat network pipes.
For Google, a .0001% reduction in user overhead may translate to millions of dollars of resource savings. Google is willing to do crazy things like run their own modified Linux kernel that most companies wouldn't bother with.
What is the end-user benefit in performance using HTTP 2.0? The only analysis of SPDY I saw indicated low single digit percentage benefit vs HTTPS. Whoop-dee-do. http://www.guypo.com/technical/not-as-spdy-as-you-thought/
Re: The 7-bit Internet
#38This sounds similar to an argument you could make for writing all of your code in assembly instead of C (or other higher-level languages.) Yes, there's a layer of obscurity between a program written in C and the resulting assembly: a tool (yes, a tool, spouting abstraction all over the place!) called a compiler. As a core tenet of engineering, we create tools that often leverage abstraction in order to let us tackle…
I find your analogy curious, because I think it's backwards. If we're going to use C and assembly, the author is arguing for C: easier for humans to read, but we'll have to translate (compile) it so that the machine can read it. Assembly is easier for machines to read (well, not really), but harder for humans to read. My "not really" bit is because the better analogy would be C to machine code. The author's point is…
I think we're addressing different points in the article, especially in that 'readability' and 'complexity' are distinct. Also, I think the author does make valid points, which is why I qualified that we can all choose our preferred places on that continuum of abstraction.
My point is that it is sometimes (or from my perspective, often) worth it to deal with more complex (as in higher-level) technologies via tools that allow us to de-abstract those technologies than to focus on using only technologies for which we can understand every detail of their implementation. Trying to understand assembly written by a human vs assembly spat out by a compiler (with its optimizations, etc.) is a very different beast, but thanks to the tools of higher-level programming languages and compilers we rarely need to fiddle around with machine-generated assembly.
Similarly, with reliable tools, we would not need to fiddle around with raw HTTP 2.0 workings, and thus rarely would the concern of immediate human-readability be an issue.
Re: The 7-bit Internet
#39For 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 feel as though the people in this thread against (well-designed) binary protocols have never tried implementing a binary protocol.
Length-prefixed fields and direct encoding of binary data go a long way to simplifying implementing a protocol.
The ease of implementation of a simple binary protocol should not be underrated.
Re: The 7-bit Internet
#40This sounds similar to an argument you could make for writing all of your code in assembly instead of C (or other higher-level languages.) Yes, there's a layer of obscurity between a program written in C and the resulting assembly: a tool (yes, a tool, spouting abstraction all over the place!) called a compiler. As a core tenet of engineering, we create tools that often leverage abstraction in order to let us tackle…
There's a broadly-held idea that passing around compiled images ready to be copied into memory as software is too fragile, arcane and low-level and that we should just put the human-readable source on the target machine to be consumed by the runtime.
Isn't that directly equivalent to having a preference for a textual wire protocol?