Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The 7-bit Internet

blog.tabini.ca

Post reply on HN
Print view View original

151–160 of 162 posts

Re: The 7-bit Internet

#151

Post by weland »

mbrock wrote: post #122
weland wrote: post #32

Earlier quoted context omitted.

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.

This is all very interesting... I feel that the document-centric request-oriented nature of the web has been a powerful influence on the design of "web applications." But we still haven't really figured out how to do it. The web has been full of applications since the beginning, no? There was no golden age of pure document sharing. So much of the web throughout its history has been CGI, ASP, JSP, ad hoc setups to pro…

> The web has been full of applications since the beginning, no? There was no golden age of pure document sharing. So much of the web throughout its history has been CGI, ASP, JSP, ad hoc setups to provide dynamic sites. Session cookies, inscrutable URLs, forms with two dozen hidden fields encoding cryptic parameters...

True, but many of those dynamic pages actually had semantic meaning in their structure. Think of a discussion forum, for instance. That's a case for which the WWW is perfectly fit.

> Calling it a day and forking it" seems in some way to mean giving up on this fruitful encounter between two paradigms.

On the other hand, this encounter doesn't look too fruitful in applications like Google Docs, Meebo or Prezi.

In the meantime, one side tries to push for things that are primarily relevant for non-semantic applications (think HTTP 2.0's binary protocol, which is all around HN nowadays), pissing off the people who primarily want to transfer semantic content, while the primarily semantic-oriented additions keep dragging the other side back. People have been building web apps with fancy UIs for almost a decade now, and there's still no decent UI builder to speak of.

Re: The 7-bit Internet

#152

Post by lstamour »

teddyh wrote: post #121
lstamour wrote: post #115

Earlier quoted context omitted.

"maintain 2 protocols" - actually, yes, I do expect browser vendors to maintain compatibility with HTTP 1.0, 1.1, 1.2 and 2.0+. By the way, you might be interested in 1.2: http://www.infoq.com/news/2011/04/http-1.2-released The way I see it, we can have our cake, both flavours. Why make someone remember different URLs? " http://" is too entrenched for when people type it in, and I'd rather not worry about browsers tr…

HTTP 1.2 is an April fools joke .

Sigh. And I knew that. Just not at 2am. (Though the way I phrased it, maybe it could slip by as an intentional link...) Thanks for pointing this out to my less tired self and anyone else who stumbles upon this thread. It's perhaps worth pointing out that HTTP 2.0 then is not an April Fools joke :D

(1.0 and 1.1 was all I knew, but Google distracted me in to thinking it was real again with those dang uncorrected news articles...)

Re: The 7-bit Internet

#153

Post by lstamour »

flipperypokery wrote: post #147
sergiosgc wrote: post #142

Earlier quoted context omitted.

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…

Those who don't understand history are doomed to misinterpret its lessons. 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 w…

> "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.

+1

http://www.igvita.com/slides/2013/breaking-1s-mobile-barrier... if you want to read about this from a mobile perspective.

Re: The 7-bit Internet

#154

Post by lstamour »

hcarvalhoalves wrote: post #81
lstamour wrote: post #73

Earlier quoted context omitted.

Right. Because the alternative, bloated pages out the wazoo makes so much more sense than having smarter Apache and Nginx servers who will do all this for you. Remember, most of the web will be connected by cell phones, we need better protocols for that.

Did you read the comment or just skimmed? I don't question the technical merits, but the underlying motivations, which I believe are fatally flawed.

Perhaps I can reply more clearly after some sleep :) What I meant is that it's to support an evolution of content from static print and "data" to dynamic, interactive and responsive content the likes of which we've never seen before on such a wide scale of platforms and devices. Write once, run anywhere truly exists for content that conforms to web standards, and HTML5 Components will push that boundary even farther. I'll admit, authoring tools and publishing techniques need to play catch up, but that's not a reason to stop progress on standards. That's only a reason to slow or change adoption patterns and usage. Build a better Wordpress, I say, one that's two way. It's not always for the big advertising players, you know...

Re: The 7-bit Internet

#155

Post by jbert »

zxcdw wrote: post #150
jbert wrote: post #123

Earlier quoted context omitted.

> 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.…

Human readability too could mean base64 encoding. 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 wheneve…

I don't disagree that human-readable doesn't mean "verbose", but in answer to:

> Why would I not save resources whenever I can, even though I don't need to do it?

It's a cost-benefit. You don't spend your evenings clipping coupons all the coupons you can (which would save you some pennies). Or if you do, you don't stay up late to do it. The benefit to you of some free time is greater than the benefit of saving the pennies.

Similarly, the cost of mild verbosity is balanced against the benefit.

Basically, I don't buy an absolutist position of "save wherever you can". There are costs to saving, make a judgement whether it is worth it.

Re: The 7-bit Internet

#156

Post by drawkbox »

pbsdp wrote: post #149
drawkbox wrote: post #95

Earlier quoted context omitted.

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…

Engineering is about making complex things simple and easy for your users . Sometimes that means increasing complexity at one level of the stack to increase performance and functionality at a higher level of the stack.

Many times in engineering the users are other engineers. Complexity only where necessary. The OSI layers beneath this layer are much more complex for those reasons. But in the end they are still simple parts to an overall complex computing and delivery system. Each engineer, if they are good, simplify things even for other engineers, this leads to less hurdles on the next platform innovations.

Re: The 7-bit Internet

#157

Post by pbsdp »

drawkbox wrote: post #156
pbsdp wrote: post #149

Earlier quoted context omitted.

Engineering is about making complex things simple and easy for your users . Sometimes that means increasing complexity at one level of the stack to increase performance and functionality at a higher level of the stack.

Many times in engineering the users are other engineers. Complexity only where necessary. The OSI layers beneath this layer are much more complex for those reasons. But in the end they are still simple parts to an overall complex computing and delivery system. Each engineer, if they are good, simplify things even for other engineers, this leads to less hurdles on the next platform innovations.

HTTP improvements are necessary. If this raises the bar past what some developers can manage, that's unfortunate, but necessary -- the current system actually prevents what better developers want and need to do.

Re: The 7-bit Internet

#158

Post by ddunkin »

pbsdp wrote: post #139
vidarh wrote: post #126

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.

Do you have netcat compiled for Cisco IOS and JunOS? If so, please send them to me, and let me know how to get them into the devices firmware.

Re: The 7-bit Internet

#159

Post by teddyh »

vidarh wrote: post #138
teddyh wrote: post #135

Earlier quoted context omitted.

No, Telnet does not, in fact, intercept any character sequences unless when connecting to the telnet port (port 23).

This is not true on the client I have on my OS X box at work, nor on my Debian and Ubuntu machines at home, nor, I believe, with pretty much any other telnet client I've used in the last twenty or so years. I just tested several to verify whether I'd somehow missed something so basic. Regardless of the issue of negotiated options, most telnet clients goes into a command mode if you enter an escape character, defaulti…

Right, the interactive escape character. That's easily fixed with "telnet -E". That is,

    echo -e "test\035help" | telnet -E www.google.com 80
will not give any help text output.

(I was, in fact referring to telnet option negotiation which will not happen if not using the telnet port. Since the escape character for interactive use is so easily remedied, it did not occur to me to consider it a problem.)

Re: The 7-bit Internet

#160

Post by hcarvalhoalves »

9h1d9j809s wrote: post #116
hcarvalhoalves wrote: post #65

Earlier quoted context omitted.

I see the proposals of binary protocols, push content, etc. as symptoms of a deeper issue. Different than the spirit of HTTP, those protocols have little to do with publishing content anymore. They are just more kludges, in the history of kludges, to patch browsers into application platforms. That mainly benefits the big web monopolists, who require the browser to be the ultimate application platform, where they can…

> That mainly benefits the big web monopolists, who require the browser to be the ultimate application platform, where they can track to their hearts content, display unsolicited advertising Please. All you need for advertising is plain text, all you need for tracking is cookies.

Read again. I'm not saying the technologies enable advertising. I'm saying it's in their best interest to have people do all useful work inside a browser, with a technology stack they control, increasing ad impressions and being able to provide ubiquitous user behavior tracking. This is the holy grail of advertising and would strengthen their monopoly even more.
Post reply on HN