Re:The resource leak bug of our civilization
by jerf on Monday December 01, 2014 @08:51AM
(#8680906)
"What if [HTTP] was a simpler, easier-to-parse format that was as extensible?"
Then it would become HTTP. It would take time but it would be inevitable.
HTTP didn't just happen. Using Fred Brooks' terminology, the real world is essentially complicated. We may pile accidental complexity on top of it at times, but the real world is essentially complicated.
While I agree that there is room for accidental complexity to occasionally be swept away and a new clean slate presented, I do not believe that a new protocol for HTTP could solve all the problems HTTP solves without being at least nearly as complex as HTTP. The set of problems that HTTP solves is a great deal larger than "request page -> get page". There's caching, proxies, security, encryption, policy enforcement, needs that schools have, needs that Facebook has... and that's still just the high-level table of contents of the table of contents of the world of HTTP. And if you think you can just ignore those cases and simplify... try it and you'll see how wrong you are.
Note I do think there is room for improvement in HTTP, and it probably isn't the direction of 2.0. But it's not like there's some sort of brilliantly simple protocol in there struggling to get out, buried under layers of cruft. It's a thorny hard problem and the result will be a thorny hard protocol. It often fails to work not because the protocol itself is broken but because people doing work in HTTP have truly failed to account for a fundamental use case properly, like caching or the use of proxies.
Also note that there's no guarantee that "simple protocol + time" will yield something any simpler than HTTP. Under HTTP is a fairly powerful idea, and there's a reason why so many Internet protocols look very similar to it. It would be easy to start with something "simpler" that turns out to grow much, much worse.
Then it would become HTTP. It would take time but it would be inevitable.
HTTP didn't just happen. Using Fred Brooks' terminology, the real world is essentially complicated. We may pile accidental complexity on top of it at times, but the real world is essentially complicated.
While I agree that there is room for accidental complexity to occasionally be swept away and a new clean slate presented, I do not believe that a new protocol for HTTP could solve all the problems HTTP solves without being at least nearly as complex as HTTP. The set of problems that HTTP solves is a great deal larger than "request page -> get page". There's caching, proxies, security, encryption, policy enforcement, needs that schools have, needs that Facebook has... and that's still just the high-level table of contents of the table of contents of the world of HTTP. And if you think you can just ignore those cases and simplify... try it and you'll see how wrong you are.
Note I do think there is room for improvement in HTTP, and it probably isn't the direction of 2.0. But it's not like there's some sort of brilliantly simple protocol in there struggling to get out, buried under layers of cruft. It's a thorny hard problem and the result will be a thorny hard protocol. It often fails to work not because the protocol itself is broken but because people doing work in HTTP have truly failed to account for a fundamental use case properly, like caching or the use of proxies.
Also note that there's no guarantee that "simple protocol + time" will yield something any simpler than HTTP. Under HTTP is a fairly powerful idea, and there's a reason why so many Internet protocols look very similar to it. It would be easy to start with something "simpler" that turns out to grow much, much worse.