Slashdot Mirror
HTTP's Days Numbered
dlek writes: "ZDNet is running an article in which a Microsoft .Net engineer declares HTTP's days are numbered. (For those of you just tuning in, HTTP is the primary protocol for the world-wide web.) Among the tidbits in this manifesto is the inference that HTTP is problematic primarily because it's asymmetric--it's not peer-to-peer, therefore it's obsolete. Hey everybody, P2P was around long before Napster, and was rejected when client-server architecture was more appropriate!"
Well, not to comment on .NET, but SOAP can really be used over almost any transport, HTTP just being the most popular.
www.beepcore.org
Who in the world would want to administer seperate client firewalls? Sure, sounds great at home with 5 machines, now do it with 5000. No way that will ever happen.
A good centrally administered firewall won't stop you from doing what you need to do. If a protocol is well thought out NAT will not cause a problem.
NAT is a horrible kludge that should never have existed. Using IPv6 with good OS- and application-level support would make network administrators' jobs a lot easier. I can see companies using IPv6 internally and over WAN's to simplify and improve the performance of their networks.
All the CNet sites are whatever.com.com.
.com.com domain, all the CNET sites can maintain their identities (news.com, download.com, etc) while sharing cookies through the .com.com domain.
It's so they can share cookies. Any site in a domain can share cookies (for example, www.slashdot.org, apple.slashdot.org, and bsd.slashdot.org share your login info cookies). That's why, for example, all the ABC/Disney sites redirect to whatever.go.com.
So, with the
Mr. Box was not saything that HTTP is not good as a Hyper Text Transfer protocol, he was stating that it's being manipulated to perform RPC, which is true. The theme of the artical was on how HTTP is bad for RPC, which you seem to also agree with.
Simply because this guy now works at Microsoft does not mean he has an agenda for evil. As a matter of fact before working for Microsoft Mr. Box started a little company called DevelopMentor, He's also written a few books One of which is concedered "The" book on COM, Essential COM, ask any COM developer worth their salt if they own a copy, they do.
I've known of Mr. Box for years now and trully recpect him as a technical writter and developer and I honestly don't think that he would shill for Microsoft.
-Jon
this is my sig.
"rtsp://" protocol, something only realnetworks software can understand
Wrong. RTSP is an open protocol. You can read RFC2326 here. Multiple implementations already exist, including an open-source one.
Well, OK.
Hey, Windows users, there is no such thing as "forward" slash, there is only slash and backslash.
I quote in full, because the lack of understanding of this Box "guru" guy is appalling:
Last things first, to clear the path: a blatant comission of the sin of conflation (a.k.a. bait-and-switch)! What does interoperability have to do with tomatoes? I guess it's a disclaimer for future incompatibilities ("hey, we already told you, HTTP is not interoperable").
Then, either I slept through all my classes on Networking, or the guy doesn't really know what he's talking about. You don't need to be Apache to be an HTTP server, the code to be a modest but fully HTTP/1.0 compliant server is not much more than the code needed to be a modest but fully HTTP/1.0 compliant client. So the issue of symmetry is more one of implementation than anything else. P2P is about roles (who's the initiator and who's the responder, as opposed to who's the client and who the server), not code (how do I write the initiating side and the responder side). Anyway, it's obvious that the code implementing the functions defining both roles will be different; otherwise, initiating wouldn't be any different from responding from the operational point of view and thus indistinguishable at any given moment. Let me stress this point: you have to be able to determine the direction of the flow at any given moment in time, even when talking about P2P protocols. It makes no sense to ask for a resource by sending it.
HTTP is not an RPC protocol, it's a file transfer protocol (as a quick perusal of RFC 2616, Section 5 will show). Anything built on top of that will be, by definition, a hack. So why so much grief?
Indeed, you can type a GET request as application/x-rpc-call or anysuch, and pass parameters on the URI. But it's cheating, isn't it? So why is using HTTP as a P2P protocol "a hack"? This is a non-issue.
Lastly:
Well, he's right on this count. But he doesn't know (or doesn't tell) why: as defined by the standard, HTTP is an application-level protocol. You can't build upon it, it's level-7, top of the stack, period. If you build upon it, you're breaking the ISO/OSI model. But aren't cookies a way to implement sessions on top of HTTP? Well, yes and no. Aren't cookies a hack? Of course. Why can't you use something like that to implement IOUs or tickets or return thunks or any other model for delayed responses? Because it would be a hack. Yes, but no more a hack than the eminently acceptable (and widely accepted) cookie hack. You can always reify state (including the result in a RPC); cookies just are a proxy for a lazily reified state.
I'm mystified (and angry) at the lack of understanding the article evidences.