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!"
don't most P2P systems use . . . HTTP as a transport?
-Peter
Anyone who has tried to understand the various "standards" for web services and their associated train wreck (I think I'm being gracious here) would realize that most of them are bolted on to a protocol that was never meant to serve them in such a way. HTTP is meant for quick requests, not monoloithic requests that take a long time.
Before you rush to say Mickeysoft is destroying the web, please realize that he's referring to web services, not your personal home page (although I'd imagine they'd like to make that proprietary too).
My Slashdot account is old enough to drink...
I don't think a P2P protocol would make more sense for me reading /. or ESPN websites. I agree that P2P could be more useful than HTTP for applications, but I don't see why they wouldn't keep HTTP around for simple browsing.
But... maybe I just answered my own question. Is this a thinly-disguised way to hide a revive of the much-touted-a-few-years-back "push" technology for the web?
-- Ed Avis ed@membled.com
This sounds like wishfull thinking. Http is over used. Every time someone wants to implement a new protocal latly , it seems that they do it over http, as opposed to implementing there own. esp, if it can be async.
-jj-
There are obvious reasons to replace HTTP - the most obvious being the creation of true stateful transactions. That said, there will be support for HTTP until 2025 at least, and ultimately legacy support for HTTP will be painful and necessary for coders.
I've been doing web app development for a few months, and the stateless nature of http is a royal pain. Pretty much the only reliable way to maintain state information, in HTTP, is through cookies.
Best Slashdot Co
"HTTP's days as an RPC transport are numbered"
HTTP works great for a large number of purposes. It will continue to work great for a large number of purposes. However, it is not so great when you are trying to build powerful RPC mechanisms like SOAP on top of it. It's the latter where HTTP will slowly loose favor.
Your web browser will still be making HTTP requests for HTML documents many years into the future...
Does anybody else find it hilarious that this guy from Microsoft says "It's all hackery, it's all ad-hoc and none of it is interoperable." I mean, this is the same Microsoft that goes out of its way to prevent MSN.com from being viewed with other browsers than IE, completely ignores HTML standards and tries to make its own proprietary HTML tags, tries to prevent Java from being interoperable, and uses closed APIs for Windows programming and proprietary formats for DOC files.
Comment removed based on user account deletion
I don't know about anyone else, but I'm not going anywhere near .NET. Applications installed on my hard drive, including opera, work just fine for me.
.NET, and no one uses it? My dad/brother were perfectly happy with office 97 until i gave them star office, and they both run windows 98SE. How soon until people get tired of having the way they compute changed and just stick with what works?
This is another example of M$'s ego. They keep trying to change the direction of personal computing and the internet, and seem to never have any thoughts about "well, what if this doesn't catch on..." What if they move all of their applications over to
The problem is, most machines aren't even really *on* the internet anymore, just on the Web. Which is not as powerful, so you end up with these godawful kludges trying to run applications over HTTP.
The Right Thing would be to get IPv6 out, make local client firewalls and sandboxing standard, and ditch NAT and central firewalls.
Yeah, right.
Instead we have SOAP, a RPC-over-HTTP kludge. We may as well run PPP-over-HTTP and have done with it...
i thought basically all web development fell into this category
But seriously, i've been involved in projects requiring using HTTP for purposes which it was not well-suited for - workaround is the name of the game. Old problems, lots of old solutions.
So well this looks like more
... the fact that Web Services don't rely on HTTP whatsoever. Sure, loading the client UI that goes and talks to these Web Services relies on HTTP, as well it should, as it's all go-fetch-me-a-web-page stuff.
However, the web based UI could easily be implimented such that the actual communication between web services is done through any IP based protocol. Right now HTTP is the one that jumps to most developers minds, but by no means is it the one that's expected to be used for longer-running services. Personally, I would expect that the web based UI would interact with some running process that would dispatch and receive Web Service data through a message queueing system that provides some form of transactional validity and security. If it's a really long-running service, then this intermediary process could exist much like a state machine, and the web UI could get status updates by hitting that state machine and getting the appropriate response (ie: "Still waiting to hear back from Microsoft's UDDI server!" or "Still waiting for that order to go through!")
So, will the new protocol help serve web pages from Mars, where the time delay a quite long?
~afniv
"Man könnte froh sein, wenn die Luft so rein wäre wie das Bier"
Richard von Weizs
Comment removed based on user account deletion
from the article: "I need a way to send a request to a server and not the get result for five days"
Why does it need to be done at a protocol layer? If I need to submit something to a server that is going to take 5 days to get back to me, I should probably have an account with that server, and when I log back in, can get that information.
It sounds to me like he's fishing for an excuse to design a new protocol for a need no one really has.
ChuckyG
I think that is the point of Hyper TEXT Transport Protocol.
The article just points out that using HTTP as a basic transport for more higher level concepts such as a Microsoft Web Service is problematic because:
a) The way most of the Internet's IP infrastructure treats port 80 traffic will not allow long durtation web service transactions to work reliably (presumably because things like NAT mapping tables will get cleaned up before the transaction finishes)
b) Because the server can't initiate a connection to a client.
It's NOT talking about HTTP being unsuitable for pushing web server content around the Internet.
Oh yeah, and all operating systems besides Windows XP are obsolete.
ROFL.
By the way, the funniest quote in the article was:
Microsoft has some ideas (on how to break the independence on HTTP)
Now that was a Freudian slip... ;-)
299,792,458 m/s...not just a good idea, its the law!
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
HTTP does have it's problems, and it's one of the reasons that Jabber has it's own internal transport protocol to accomplish IM.
I've seen other proposals for HTTP replacements and have been less-than-pleased by their complexity and design. Based on what I've learned from Jabber, and great feedback from many in the open source and standards communities, XATP was born:
http://xatp.org/
XATP, the eXtensible Application Transport Protocol is very simplistic and geared to operate at a layer below content, identity, framing, and other application-level issues. Check it out and offer feedback or participate if your interested.
Jer
I seem to remember that some time in the past MS claimed that the Internet was obsolete and the MicroSoft Network was the future. I think Unix is also obsolete according to MS.
And of course I am obsolete since I refuse to view MS products as anything else than toys. Admittedly by now toys that actually have some level of stability and can be used for some (limited) tasks without too much hassle. But as long as they insist on sitting on their island (admittedly a large one, but instable and plagued by document-rot), I will not consider their products "professional" in any sense.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted and ignored otherwise.
The link is wrong in the post...but somehow it still works??
The link isn't wrong. Com.com is the C|Networks portal, so it's essentially C|Net, which in turn owns ZDNet.
Didn't Cringely claim several months ago that they were going to try to do this? Well, not quite, but back in August he wrote:
So they decided to go up one level of abstraction. Hell why not, that way they break even more competing products.
Nope, no sig
Seemed to me like Mr. Box raised some good points. Unfortunately, he works for Microsoft, which means that your first impression is "Oh my gosh, Microsoft wants to stamp out HTTP and replace it with some evil, proprietary protocol" (it was my first impression, anyway). Looks like it just means that we'll also be making requests like "newtp://blah.blah.blah" someday.
I'm in the middle of a project where the one-way nature of HTTP is a bit inconvenient at times so I can see where he's coming from.
I live ze unknown. I love ze unknown. I am ze unknown.
The link is wrong in the post...but somehow it still works??
... whatever floats your boat. :)
Indeed. http://www.com.com" is owned by CNET. A pretty dumb way to name your site, but
It doesn't look like it's used directly though, I get 'connection refused'.
----- rL
Gee, I wonder WHAT shape will that holocaust take. Maybe it'll be a killer protocol that pursues and assasinates other protocols? Damn, Mr. Box, use the proper words, will you?
This works for small transactions asking for Web pages, but when Web services start running transactions that take some time to complete over the protocol, the model fails. "If it takes three minutes for a response, it is not really HTTP any more," Box said.
Well, of course it isn't. Is it, then, HTTP's fault that it doesn't work perfectly when used for stuff it wasn't designed to do? Hell, I'd love to see telnet-over-HTTP done while we're at this.
"We have to do something to make it (HTTP) less important," said Box. "If we rely on HTTP we will melt the Internet. We at least have to raise the level of abstraction, so that we have an industry-wide way to do long-running requests--I need a way to send a request to a server and not the get result for five days."
Maybe if we get back to use the proper protocols (say, why don't we rely on ftp for transferring files, for example?), we wouldn't have the current "problem".
Another problem with HTTP, said Box, is that it is asymmetric. "Only one entity can initiate an exchange over HTTP, the other entity is passive, and can only respond. For peer-to-peer applications this is not really suitable," he said.
Of course it isn't, HTTP is designed with a client-server model in mind.
In my humble opinion, this is just the first step from Microsoft for a new FUD campaign against HTTP: "First, we show everyone how HTTP isn't any good, then we roll over our brand new protocol that supports all of HTTP's capabilities, and lacks its limitations. Buy it from us, your beloved Microsoft!".
"Microsoft has some ideas (on how to break the independence on HTTP), IBM has some ideas, and others have ideas. We'll see," he said. But, he added, "if one vendor does it on their own, it will simply not be worth the trouble."
This, of course, implies that Microsoft won't control the new protocol on its own... not at first. They'll just "embrace and extend" it later.
"Trust me - I know what I'm doing."
- Sledge Hammer
while it's certainly true that http was never originally ENVISIONED as a protocol to serve shoutcast/icecast streams, for example, it's usefulness to that purpose is a tribute to how well the spec was thought out. the simple fact remains that it's an incredibly versatile protocol which can be (and is) used for nearly every data/media transport/request over the internet. microsoft is going to have to do something FAR more impressive to convince me they have a good reason to scuttle the most re-purposeable protocol on the internet.
ever wonder why 99% of ANY urls you see start with an http? ever wonder why flash webpages don't start with something like mmfttp and shoutcast streams don't start with plsttp?
wonder.
I share the growing concern that wrapping web services in HTTP is akin to putting a ladder outside your house next to an open window. SOAP is being touted for it's ability to get through corporate firewalls via HTTP. I can't believe someone would consider this a feature rather than a bug in the spec.
.NET team at Microsoft is listening to this guy.
We need a wide range of new protocols for web services with security and scalability in mind while they are being developed. We don't want to use HTTP for more than HTML. We want to be able to control who does what, where and to whom.
I hope the
There is a good point that HTTP over TCP doesn't work nicely when there is lag between request and response. It keeps that nasty TCP connection going the whole time, tying up resources. For higher volume, and a more flexible scheme, go to an ACK-ed UDP transport.
Client: Hey! I want X!
Server: ok...
[time passes]
Server: (X)
Client: got it!
In TCP, the "ok..." and "got it!" phases are implicit in that TCP will tell you your message got through. Lots of overhead that the protocol doesn't really need though. In my Networks class we hear the End-to-End argument, that end to end the protocol should be designed to exibit only the state and information transfer it actually needs. Using TCP is a shortcut, and lazy. Good for getting things working fast, not optimal in the long run. Just like the STL, but that's another rant.
Start Running Better Polls
www.beepcore.org
Hmm... An intelligent statement coming from Redmond?
While I'm certain a lot of this is about leveraging Microsoft to control the 'next' major form of web transport, the engineer in question is right about one thing... HTTP is overused.
A lot of P2P stuff could be a lot more efficiently and resource-considerate if it were to use UDP-style transmission like email and some online games rather than 'Virtual Circuit' style TCP connections. Another sweetener to add in the pot is to use Parchive (PAR) style error correction on your datagram packects in order to be more tolerant to faults, etc...
sender transmits udp0-6, upd7 is lost by receiver, receiver requests par(0,6), sender transmits, receiver self-generates upd7, sender transmits upd8-999 with no further par requests without ever trying to figure out if receiver got all those packets.
It's async. It's resource considerate, and it could do a great deal to ease download over p2p architecture.
The next Slashdot story will be ready soon, but subscribers can beat the rush and slashdot the links early!
Or maybe not - I suppose one way to look at it is if big biz, sucking from the MS teat, all herd off onto MS's "better" protocol, the rest of us can continue to use HTTP without the control freaks (read: corporations) trying to own it.
Please Rate my comment (and help support Fre
If he was such a guru maybe he'd have realized that http is "hypertext transport protocol" or something like that, not "heavenly total treatment protocol"
It was designed to --- get this, kids --- deliver WEB PAGES!!! I once heard rumors of this other evil, called ftp, that was once used as a "file transfer protocol!!" The nerve of some of those early networking types!
Really, though... there are just about as many potential protocols as their are potential uses. So http doesn't lend itself to your insecure privacy invading microsoft-enriching wet dream of global domination. GET OVER IT or LEARN TO USE AN APPROPRIATE PROTOCOL. Really!
I don't see my linux box making http requests every time I want to mount an NFS share, so why should microsoft's next weapon use it to rob me of my money? HAH! Guru indeed...
COBOL is still around. FORTRAN is still around. The reverberations of 80-column cards can still be heard. Screen-scraping is alive and well. HTTP will be with us when Bill Gates' ghostly presence is roaming Internet2.
seem to remember that some time in the past MS claimed that the Internet was obsolete and the MicroSoft Network was the future. I think Unix is also obsolete according to MS.
And of course I am obsolete since I refuse to view MS products as anything else than toys. Admittedly by now toys that actually have some level of stability and can be used for some (limited) tasks without too much hassle. But as long as they insist on sitting on their island (admittedly a large one, but instable and plagued by document-rot), I will not consider their products "professional" in any sense.
Incidently the only argument in the article (aside from the "argument" that P2P is better than client-server, given as dogma) is that there are problems with transactions that have several minutes connection time. I am sorry, but I don't see how that makes http obsolete. First these long transaction are not that common and second they work fine. Or are we going towards an Internet where a telnet/ssh connection will be terminated after 3 minutes, because the backbone cannot cope?
Pure FUD, as far as I can tell.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted and ignored otherwise.
Using TCP is a shortcut, and lazy.
Until you end up reimplementing half of it on top of UDP. Badly. And yes, I've seen this multiple times.
Enough with the NIH, please? There are many years of effort in the common TCP stacks, and many subtle things they do right that you'll miss the first dozen implementations.
For the love of god, if you need a substancial subset of TCP's features, and can live with the overhead, use TCP!
HTTP. I know about java, et. al. There're lots of things that can run over tcp/ip, the trouble is that people want to use a web browser as their GUI, and the browser is designed to do http. Everything else is just a bag hung on the side of the browser.
Best Slashdot Co
Excuse me, but the article says that HTTP will still be around after the world ends, so that hardly implies it's going away. The implication is (correctly) that HTTP should be used for everything.
Inflammatory headlines and spinning of the stories really does no one any good, and we have to slog through dozens of responses by people frothing at the mouth because they only read the intro paragraph.
HTTP,
Was designed to transfer hypertext, not be the end-all-be-all RPC transport of the Internet.
Microsoft and MANY others made a big mistake of using it as their protocol of choice for everything Internet related.
Using HTTP as a catch-all protocol defeats the whole purpose of having different ports if everything is on 80. It makes administration a headache, and it lulls people into a false sense of security.
(Oh, it's only HTTP, we can leave that open...what did you say about a SQL Server HTTP interface? And the SA password is blank on your local development system?)
HTTP, The HyperText Transfer Protocol; use it for what it was designed for.
I make many Web Apps. And I know from 1st hand experence that HTTP it is not the best protocall for making apps. Keeping state is anoying eather you use cookies or make more of hacking tricks, All the browsers seem to handle more advanced html commands differently. HTTP is great for Message boards like Slashdot or simple online ordering. And of course content information. Where it is basicly place your data and get a responce. But if you start working on more advanced features HTTP is anoying because your program spends a lot of code to get your data and memory in the right spot and it does its output and it is gone. A different protocall for the more advanced features could be more handy so we are not hacking a way to keep state. Making Javascript to do realtime input checking. Having in intire page reload to update some data. (remember I am tring to use as simple HTML as possible for browser compatability). The Web is now being used way beyond it intent and does need a new protocall for more advanced documents.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
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.
I guess Microsoft needs to think outside the box.
The Virtual Bookcase: book reviews
Did anyone else notice that Mr. Box used the word hack properly? ("It's all hackery")
Malcolm solves his problems with a chainsaw,
And he never has the same problem twice.
To be fair, the engineer interviewed acknowledged that HTTP is the "cockroach of the internet ... after the after the holocaust it will be the only protocol left standing."
.Net and strikes me as more of a macguffin than a critical limitation of the existing infrastructure. This is just the sort of strawman Gates & co. love to use to insert new technologies whose only true purpose is to increase the public's dependence on the Microsoft MotherShip (TM).
Of course, that is as it should be. Even bad standards have a tendency to live much longer than anticipated and good standards are rarer than hen's teeth. As a good standard, HTTP rightly deserves a long and fruitful life.
The nefarious implication is that Microsoft is pushing their own propriety replacement for HTTP in order to lay down their infamous hammerlock on the 'net just as they have on so many other sectors of the industry.
While the engineer raises some fairly valid points regarding the applicability of HTTP to alternative networking models such as P2P, I'm sure that most people will read these comments as a thinly veiled plot to extend Redmond's Global Dominance (TM) - and I'm not sure that they would be mistaken.
Certainly, the issues mentioned regarding high latency network operations smacks of the distributed applications model of
While few would (should) argue that HTTP has room to grow, and may ultimately be supplemented or even supplanted by other standards, I am very leery of such spin coming from such a notoriously anti-standards organization.
Be afraid. Be very afraid.
The problem with HTTP, as with any stateless protocol, is that there often are (or should be) relationships between requests. Ordering relationships are common, for example, as are authentication states. Stateless protocols are easier to implement, and thus should be preferred when such "implicit state" is not an issue, but in many other situations a protocol that knew something about state could be more efficient. All of this session-related cookie and URL-munging BS could just go away if the RPC-like parts of HTTP were changed to run on top of a generic session protocol.
Another error embodied in HTTP - and it's one of my pet peeves - is that it fails to separate heartbeat/liveness checking from the operational aspects of the protocol. Failure detection and recovery gets so much easier when any two communicating nodes track their connectedness using one protocol and every other protocol can adopt a simple approach of "just keep trying until we're notified [from the liveness protocol] that our peer has died". This is especially true when there are multiple top-level protocols each concerned with peer liveness, or when a request gets forwarded through multiple proxies. As before, having the RPC-like parts of HTTP run on top of a generic failure detection/recovery layer would give us a web that's much more robust and also (icing on the cake) easier to program for.
I don't know if any of this is what Don Box was getting at, but in very abstract terms he's right about HTTP being a lame protocol.
Slashdot - News for Herds. Stuff that Splatters.
Capabilities like chunked-encoding allow HTTP to not know how long the response will be before transmission begins. Explicit instructions for weather the connection is to remain open or closed after the request is complete. Support for acknowledgment before large data chunks are sent to server. Mandatory backward compatibility certainly hasn't taken anything away from the party. All of this is perfect for Client-Server, yes even "monolithic" actions.
Now if you want to use HTTP to do P2P, then most likely you're only doing it so corporate users can flow out from behind their various firewalls without getting special permission from the IS department. Perhaps, HTTP isn't right in those situatins, but that doesn't mean something is wrong with HTTP. Put the blame where its due.
I know I'll get moderated down for saying this, but this seems to be a problem lately. Mis-information.
.Net engineer:
The article does not say that HTTP's days are numbered. They are simply saying that HTTP does not work for RPC, and they are completely correct. If I may quote from Dan Box, the
"However, there is nothing wrong with HTTP per se, as its ubiquity and high dependability means it is the only way to get an a reliable end-to-end connection over the Internet"
That doesn't sound to me like he's trying to get rid of HTTP, or that it's going away.
HTTP is perfect for what it is used for, but when you get into things where you need real-time processing of data both ways, HTTP simply does not work well. This is all that Dan Box is saying.
Remember folks, just because it's Microsoft does not mean they are always wrong or evil.
Seems that this article reveals many of the fundamental flaws in Microsoft's view of HTTP. The idea that HTTP is fundamentally a RPC protocol is somewhat out of line. Of course, that view is precisely why .NET services run on port 80 -- most firewalls don't block it so they can get around security.
In a very abstract view, HTTP could be a RPC protocol, but it isn't the same kind of RPC that Sun RPC or even java's RMI (Remote Method Invocation) cover. Sure you can send data back and forth and even cause the server to do some action, but that isn't the design of the protocol. Unlike RPC, HTTP provides no inherent mechanism for passing arbitrary objects -- only text. There is no marshaling of data types at the protocol level. The protocol isn't designed to be used by an application to do anything but retrieve data.
With XML there is some standard mechanism for packaging arbitrary data types to be sent over HTTP, but this isn't an inherent part of the protocol. The unpacking and reconstructing of these is still at the application level (at best the interpreter of the call will do it so the programmer doesn't have to think about it), but the web server won't have it's primary purpose be marshaling of datatypes -- just executing the requested file (assuming it's a CGI type object) or returning the contents of the file for a normal web page.
There's more to RPC than just a request and a reply -- generally more than just a few functions are made available, HTTP only really has GET, POST, HEAD, and maybe CONNECT for proxy servers. How these are handled is up to the server author -- in the case of Microsoft, they want to think of it as RPC, are we suprised that they have so many security flaws in IIS?
I've read this article twice, and I'm still not getting anything other than some obvious remarks. The worst part is that he's not offering much of a solution either. "Well, the big guys have some ideas about it..."
Oooooooookay.
So HTTP isn't sufficient for a client and a the server to have intimate discussions. We know that. So P2P can't really work on HTTP. DUH we know that. So does he have a magical, better protocol?
If he's saying that web-browsers should have more robust protocol support, that's fine. I just think he could have made that point a little clearer. Let's say that was what he was saying... doesn't that propose a problem? One really nice advantage to HTTP is that's well developed and about anything can be made to talk to it. But what if another protocol comes around? What if that one protocol turns into 2 protocols? What if it turns into 10 or even 100? This will start over a brand new browser race, and I *reallY* don't want that. Just when the net starts to get settled on standards, they wanna turn it upside down just to implement a protocol they think is necessary.
I dunno... I wish this guy had provided more of a description of what he thinks would be appropriate, rather than saying "There's a problem!! There's a problem!! Fix it!! And give me fame for pointing it out."
"Derp de derp."
Blah. Do you plan to mandate content rating standards for TV, phones, radio, school texts, magazines, newpapers, books, chewing gum wrappers and owners' manuals as well? Why? Or, why not?
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
He is not talking about web applications as you know them. What I believe he is talking about is the webservices model for remote procedure calls as part of the internals of applications. An commonly used example of this would be an application on your computer requesting a stock price from a stock price webservice, which is then used by the application, not displayed in a web browser.
What they effectivly have created is a nasty implementation of "one-way-corba", which seems to be his complaint (and rightly so!) It is a real pain in the butt to design any complex distributed application using soap calls for everything, due to the limitations he talks about.
What he wants is something like corba, without the problem of be firewalled up the wazu, like everything but http!
Distributed apps over an IP network? Easy. Distributed apps over the everything blocked but application level http internet IP network? Hope you have a simple app!
Firewalls are put up purely for the reason of not allowing things like this. The problem is now there are too many firewall managers out there who either don't know how, or refuse to open ports which makes all communication except application level httpd (as opposed to raw port 80) impossible to base a commercial application on.
-Pete
Soccer Goal Plans
I'm not calling for running every service known to man on Internet-connected machines, shutting stuff down is great. No argument.
What I do think is that ideally we should have honest-to-god IP to every desktop. No, I don't think this is 100% realistic, but I think it is the ideal.
It's all well and good for the central firewalls to block certain ports, but nothing is enforcing what's really running over those ports. (PPP over DNS, anyone?) Securing the desktop is key; once you've done that, you can open it the network as far as possible so you don't have to deal with this everything-over-HTTP b*&#%&#.
I knew it was only a matter of time before Microsoft realized it didn't need HTTP anymore. Granted, that isn't *exactly* what this article is talking about, but I think they're just warming up. If you read carefully, they're not just attacking HTTP as an RPC transport, but HTTP because it is an RPC protocol.
Why bother with HTTP, FTP, SMTP, POP, IMAP, etc when they control most of the clients and almost half the servers on the Internet. They could replace all those with their own set of protocols or, more likely, a single MS-specific protocol. They say they're already working on some new RPC solution right here in this article. It isn't too hard to imagine them introducing this WindowsProtocol on the server and in some beta of MSIE. Then MSIE starts to try to use WindowsProtocol for any network communications before falling back to the standard protocols. In 3-5 years when they're up to 60% or 70% of the server market, server side Windows has an option that is default "on" that disables non-WindowsProtocol connections and client-side Windows starts asking the user if they want to enable connections to "legacy" services, while warning them that it isn't Microsoft so it can't be good. After that, who would run a server that can't accept connections from 90% of consumer computers?
Of course I don't want this to happen, but what's to stop them? I doubt the <5% of us that realize its wrong will be able to.
I don't see the world changing so easily.
The use of HTTP has just caught fire in the last 5 years and the rest of the world has just gotten use to browsers as they are now. I cannot see the momentum of the web changing simply because M$ wants it to. People use it, people need it, and gosh darn it, people like it. Ain't gonna happen any time soon.
The great thing about HTTP to me is all the stuff that was left out. And if you really want that stuff, there's WebDAV, which also seems to be a decent protocol - but I'd have to look into it more to get a better idea.
For those people who don't like a gajillion different services running on port 80, then don't run them on port 80! You could have a user-facing webserver responding to port 80, and an XML-RPC server responding on port 8080, and a SOAP server on 8081 - there you go, problem solved.
The real problem presented by this article - of long-running transactions - definitely is outside of the scope of HTTP. But the best solution to this might be another protocol on top of HTTP. I imagine something that initiates some transaction with a transaction-id, then closes the connection, and waits (possibly days) for a connection to come back with that same transaction-id. Voila. Problem solved. Of course there'd be more to it than that, but that's the basic idea.
Amen, add to that
load balancing (ok, related to uptime)
resource consumption (stateful firewalls and the servers themselves)
Also from a theoretical point of view, I don't think that the asymmetric nature is not suitable for most kind of webservices I can imagine.
Why should webservices include P2P for chrissake?
Also, I don't want to expose my internal network to incoming requests of this nice new symmetric protocol, just to be able to use some future possible webservices like online banking.
I want it asymmetric, dammit.
Maybe I'm just getting a little George Carlin- grumpy lately, maybe it's because I'm writing a eulogy for a friend's funeral, maybe it's because I'm sick of people at MS attempting to form competent sentences (please, stick with those inspired dance routines!), but please tell me: What's days aren't numbered?
HTTP has its issues, but referring to it as "the cockroah of the internet" and saying its days are numbered, and then saying that MS has a P2P solution!, just goes to show that not only are they power hungry in Redmond but seriously power-tripping...
Arrgghhhh....
That may well be the case. Look back at the famous Microsoft "Halloween Memo", which contains a discussion of how to reduce the value of the "wire protocol" (i.e. TCP/IP, HTTP) in favor of putting value into the "services and implementation".
From that memo:
...
Make Integration Compelling -- Especially on the server.
MSMQ is a great example of a distributed technology where most of the value is in the services and implementation and NOT in the wire protocol. The same is true for MTS, DTC, and COM+.
... The rise of specialty servers is a particularly potent and dire long term threat that directly affects our revenue streams.
So it's an established strategy of Microsoft to come up with ways to mahe HTTP less important. The key issue here is that if the value is in an openly documented protocol, anyone can interoperate with it. If proprietary software, preferably protected with intellectual property rights, is required to interoperate, those annoying "specialty servers" (by which they mean HTTP-based web servers) just go away.
1. As everyone knows, the WWW is the Internet.
2. Since the web runs using HTTP, http runs the Internet.
3. HTTP can't do everything the Internet can offer.
4. While there are other protocols out there (like ftp, p2p, telnet), only hackers and pirates use them, so they must be insecure.
5. Therefore, we must change http or the Internet is doomed.
The Internet is generally stupid
Try sending an email to MS customer support
-- It's better to be pissed off than pissed on.
In the Halloween memo, some Microsoftie argued that their main defense against Open Source and Free software would be theb 'de-commoditization' of the network protocols - that is, getting people to use proprietary protocols, that MS can control, rather than standard protocols, which they can't and which anyone con implment servers and clients for. I've read the link, and it's garbage. For example:
The problem, said Box, is that the intermediaries--that is, the companies that own the routers and cables between the client and server--will not allow single transactions that take this long.
Complete and total nonsense. The intermediary routers have no idea that your session has taken 5 minutes and couldn't care less. (Some firewalls or edge-routers with reflexive access lists may need their timers adjusted, but these are at the ends of the conversation, not in the middle.)
I need a way to send a request to a server and not the get result for five days."
It exists. Its called email. Hack up an SMTP client and server app and you're done.
The reason that peer-to-peer applications do work today, said Box, is that programmers create hacks to get around the limitations of the protocol, and this is not good.
Stupid and irrelevant. P2P may need different protocols, but this is no reason to stop using http in general.
My experience has been that technical people tend to focus honestly on facts. The fact that so many of Microsoft's technical people lie so much is further condemnation of the inherent dishonesty of their corporate culture.
"that's not encryption - it's a new perl script that I'm working on..." - from some Matrix parody
MSTP .Net
.Net which will be used by the WWN (World Wide .Net) for anything from ms-mail (sending electronic messages to friends and family) to paying your ms-mortgage.
Microsoft will be anouncing Microsoft Transfer Protocol
I have a website. It's about Macs.
"If we rely on HTTP we will melt the Internet. We at least have to raise the level of abstraction, so that we have an industry-wide way to do long-running requests--I need a way to send a request to a server and not the get result for five days."
If I am reading his statement correctly, Box feels HTTP is not suitable for processes that take long period to get a response. Even if you remove HTTP layer from SOAP, you would still have a problem. Say some one decides to by pass HTTP, use raw sockets and establish persistent connections. This means a stateful application has to be built on top of SOAP. I'm just guessing, but if Box is saying RPC has to have sessions and be stateful, that isn't a full solution. If a process like "place a stock order for MSFT when the price is less than 50.00 buy," a stateful application may not be the best solution. It might take 1 day or 2 months for the price to drop below $50.00.
Microsoft is a supporter of XLang which tries to address the problem of stateful transactions. One of the problems of this approach that I can see is it is limited in scalability and timeout. Once you say all transactions need to be stateful, what is an acceptable timeout? Do all transaction require the same timeout period? What are the rules governming timeout, persistence, and garbage collection of invalid/expired states?
Why not use event based protocol with rules to provide a higher level of abstraction than XLang. The way XLang treats transaction is with case statements. On the surface that sounds fine, until you realize for every company you do business with, you will have to add cases to handle new situations, which rapidly makes the system harder to maintain. EBXml in my mind uses a better approach, which divides business and functional logic and suggests rules as a possible mechanism. HTTP isn't really the problem for long processes (as in weeks and months). A better solution is event based protocol, so using HTTP isn't a big deal. This doesn't mean there are cases where HTTP is really bad for transactions. Cases where response time is a huge factor in processing a transaction, a persistent connection would be more suitable. Things like day trading applications where response time affects the price, you would be better off using persistent connections for RPC. It would suck for a day trading application to loose a buy order because there was a sudden spike in requests and the system couldn't reconnect to send confirmation. Having a persistent connection in this case is the best solution, because response time has to be rapid.
How is XATP better than BEEP?
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.
If you read the title of his post, Napster and IRC are very, very similar.
IRC -> talk to people and get them to transfer a file to you. the file is transfered directly to you aka p2p style. However, would you say that IRC is p2p? No it's client-server.
Napster -> type in search box that sends a search request to a CENTRAL SERVER. Central server finds all matches to your file and tells you who has the file. You download a file by contacting the host directly and d/l the file (except when the file was behind a firewall, I think that napster would d/l it for you through the fw). This method is exactly like IRC with a built in search engine.
Yeah, I know with the Linux-hype over, some people feel very "objective" when they treat Microsoft's marketing schemes like the word of god.
However:
Will it become the standard on Windows? Sure, just like the Win32API - just like any api Microsoft pushes.
Will it harm or endange other operating systems? No. Worst case is that everything stays the same and Linux can't run Windows-programs. Best-case is that Mono allows Windows-compatibility which would benefit Linux greatly.
I've always enjoyed a joke along these lines. It starts with a philosophical question...
If all of the technological progress on Earth was suddenly destroyed in an instant, what would happen? Well, within a week, someone would have Linux running on something...
Sure both have flaws. But they are so entrenched, they'll never be displodged.
The problem...is that the intermediaries--that is, the companies that own the routers and cables between the client and server--will not allow single transactions that take this long.
Nonsense
Transactions comprise state, and the state is on the clients and the servers, not the routers.
Routers just move packets.
And cables...cables just carry electical fields.
Of course HTTP is dead! All I type in now to get to a site is WWW...
You have to take into account Microsofts vision of the internet being a Single System Image (running MS distributed Total World Domination protocol, of course), with nodes being partitioned on this single system image (this is their 10-20 year plan).
Permanent connection states are useful in that context. Over rpcish services, or http, it would be very difficult to gain the form of control over connecting machines that a single system image would require, since much of it by design is user request oriented. Two way RPC calls wont go through corporate firewalls in the necessary fashion. So they need to push into a different way of communication to loosen up the control that corporations want to retain over their networks and consumers to some extent want to retain over their PC's. Making p2p long-term connections ubiquitous would lay the ground for that in the way they need.
That's why we have 65535 ports, to allow for better simplification of protocols. Unfortunately some peoples' idea of security is to clamp down on as many ports as possible. Even more unfortunately, they don't seem to realize just how easy it is to tunnel over HTTP or any other protocol, so all they've bought is the illusion of security at the expense of complexity.
Perhaps the others things that should be dead are the Great Divide at 1024, or at least move it up a bit, and perhaps RPC, itself. I need to understand the security implications of RPC - whether it truly can be secured, or if rpc.statd exploits will haunt us until the Day of Valenti. (When the Internet becomes a TV-like Radio-like broadcast-only medium.)
The living have better things to do than to continue hating the dead.
The only reason that all these applications run over HTTP is so that the applications don't have to worry about Firewalls.
Business Network administrators don't want employees downloading music using napster, Real, Quicktime, or WMA. Except for napster, all of those applications run more efficiently over their native protocol than HTTP, but they fall back to HTTP and make it through the firewall when there is an issue.
So, call it like it is - they are just looking for a more efficient way to bypass firewalls.
On the other hand, if a service is explicitly named in their new standard, then it would help administrators. Maybe the next generation firewall would be able to be configured for: OK to HTML, but any RTSP requests get logged and sent to NULL.
JB
"But, he said, we can't stay on HTTP forever, despite all the investment and engineering that have gone into it. Among the problems with HTTP, said Box, is the fact that it is a [Not Owned By Microsoft] Remote Procedure Call (RPC) protocol; something that one [Non-MS] program (such as a [Netscape] browser) uses to request a [Potentially Unlicensed] service from another program located in another [NOT WINDOWS] computer (the server) in a network without having to understand [Proprietary] network details.
"We have to do something to make it (HTTP) less important," said Box. "If we rely on HTTP we will [Never Own The Internet Right Down To The Roots]. We at least have to raise the level of abstraction, so that we have an industry-wide [Monopoly] way to do long-running requests--I need a way to [Make Money Writing Books On How To Use Our Protocol].
HTTP is obsolete when it is replaced a variant of RFC1149 in which pigs fly.
Escher was the first MC and Giger invented the HR department.
that may or may not exist.
Just because I get an email from some machine, doesn't mean that it really originated there or that it wasn't maliciously crafted or altered by some sleeper virus.
You know why M$ wants to get rid of the TCP/IP stack don't you. They didn't write it, and it works. It replaced their own, which didn't work.
They want to stamp out any trace of non M$ code in their OS.
Maybe BelCore or Multics organization, or even IBM should sue them for copyright or patent violation on the use of recursive structures like sub-directories.
If they rip out the stack, I predict a wave of new virus exploits the likes of which hasn't been seen yet.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
He must be accessing a Microsoft-based server if he needs to get a result in five days! :)
It works! Therefore it is obsolete! Maybe we should replace it with NetBEUI? Huh? Let's break all the existing web applications all at once and start over with a buggy, untested, unproven, bloated, unnecessary, poorly documented protocol with no tools which nobody uses yet.
Ever try to get "Network Neighborhood" to work in Windows 9x? I've never seen HTTP not work.
Leave it alone. It works.
Comment removed based on user account deletion
you seem to be confusing IRC with it's DCC extensions.
IRC is very client server.
Napster is/was irc like in that the central server connected people but then it initiated DCC transfers.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
"I need a way to send a request to a server and not the get result for five days."
No doubt so the server can be rebooted three or four times...
i know! how about letting microsoft embrace and extend HTTP and make a new protocol that they control.
they can start implementing it in IE and Windows first, then over time completely remove support for things like HTTP.
i think i just threw up in my mouth.
HTTP is a protocol that was developed as a solution to a problem. That didn't mean we stopped using POP, FTP, Gopher, Telnet, KERMIT, etc., as they were developed to solve different problems. Now the new problem is Web Services, and the solution should not mean that we will stop using HTTP it to deliver web pages, or FTP to move files. We should not fear a new protocol (assuming it is good & worthy). As long as the solution has an IETF RFC number, with all the consultation and work required, it can be implemented by anyone. Remember HTTP wasn't invented by Microsoft, Netscape or even Linus. If you don't want Microsoft, AOL, Oracle or the MPAA developing the next solution, then come up with a great idea and start submitting RFCs.
Microsoft (or at least it's engineers) want one whiz-bang protocol to service everything. Why? Humm. Control? Nah, they'd have to standardize it.
Why the rush away from streamlined protocols? Why not create a menu of simple and useful protocols that do one job and do it very well. By having a so-called "super protocol" that handle everything, you end up with a bloated, slow, and ugly mess.
What do they want to replace it?
Oh, I bet this is a ploy to duck around that Windows isn't powrful enough to handle large web services... oops, I've said too much.
Price, Quality, Time. Pick none. What, you thought you had a choice?
This simply won't work. Application service providers simply don't work for the masses. NOBODY likes the concept, even die-hard Microsoft fans are rather sceptical about it.
What's the point in sending all your data around the world constantly anyway? Who will pay for the bandwidth? What's the added value? Why should anybody upgrade Office if everybody uses Office 97 anyway?
Do you think a company this large, with this vast amount of money, would be stupid or good?
Stupidity is directly proportional to company-size.
See for yourself., it's just a cartoon, but it's closwer to reality than most people think.
Because Microsoft cannot control it. And they haven't figured out how to corrupt it like they did Kerberos. So it's gotta go.
Yah, let's throw out a simple protocol and replace it with something that only people who've been to a half dozen Microsoft approved training classes can understand. No one really believed in that Open standards stuff anyway. IMHO, Microsoft has really come full circle now. At one time (back in the earliest days of the PC) they were the ones encouraging people to use PCs and escape the tyranny of the priesthood inhabiting the corporate data center. Now it is Microsoft that's encouraging the use of ever more complex technologies that no one except... tada!... another priesthood will be able to understand.
And Microsoft doesn't want to come up with something that would coexist with HTTP. That would make it too easy to label their technology as proprietary and easy to dismiss. Of course, even today, can anyone really argue that Microsoft's products are any less proprietary than the products they were competing against when Microsoft was the underdog?
Personally, I smell some Microsoft software -- loaded down with more software patents than you can shake a stick at -- just waiting in the wings to be offered up as the silver bullet that will solve this (artificial) protocol crisis. Just wait until Microsoft starts pushing the idea that all the software you are currently using for Internet-related things should be replaced. I can imagine a backlash like you wouldn't believe.
I recently read an opinion piece -- wish I could remember where -- that made the comment that Microsoft's arrogance would eventually cause them to do something that would cause their customers to run away in droves. I think that the author was really onto something.
CUR ALLOC 20195.....5804M
You've clearly never been a user on a network with stupid-bitch admins who block everything.
The fact that your employer's organization obviously leaves a bit to be desired is not something that can be solved with software engineering.
On the other hand, the fact that the admin at my site is calm and reasonable about this sort of thing is cancelled out by these idiotic decisions to run everything on port 80.
Don't always assume everyone else is in a boat full of shit.
--saint
If you want to know how complexity is, when a webpage is replaced with a .net solution, then have a look at the OLE2 "hello world" application source code.
.NET.
What are you talking about? OLE2 has nothing to do with
Please, get a grip. And stop smoking that which makes you paranoid.
Si
Coming soon - pyrogyra
ADMISSION: This post is the result of original ideas added to shameless [plagiarism | merciful summation] of other posts on this topic.
.)
:)
From the article:
I need a way to send a request to a server and not the get result for five days.
How about email?
As so many people have said, the whole problem comes from an over-reliance of HTTP. If you need the request in 5 days, you probably need some other kind of service.
However, his complaint about the time-frame of HTTP requests has deeper implications than he perhaps realizes. For example, if your request takes 5 days, you'd better be ready to compensate your content provider for machine usage, because it must be extremely resource intensive. (Maybe MS passport could help out.
If I'm requesting a reply over a 5-day time frame, ideally I would not need to have my machine powered up to receive the replay, as most machines are turned off daily. So, some kind of asynchronous protocol with intermediate storage -- like email -- would be required.
So, we need a service that checks for the latest server responses whenever you start it up, and automatically keeps track of how much you should be charged for each transaction. Actually, I think an HTTP/SMTP implementation would not be poorly suited, at least with a Free Software application server doing the heavy lifting. (See another posting on MS and intellectual "property" sharing.)
A new PHP function: do_5_day_request_and_charge_for_it($user, $args)
{
do_lots_of_stuff($args);
charge_lots_of_money($user);
}
I'll write that function if you promise royalties off each function call
Of course, if you wanted a seriously secure system, you would either require credit card info beforehand or require payment before issuing the response (at least for new users) to discourage fraud.
It's nice to see Microshaft coming around. :)
Steve Magruder, Metro Foodist
I did a little searching based on the phrase "replace HTTP" and found the link
http://apachecon.com/2001/EU/html/speakers.html
Which points to decsriptions of workshops and seminars being discussed at Apachecon, the parts relevant to this discussion being:
Roy Fielding
Sessions: waka: a replacement for HTTP
Roy T. Fielding is chairman of the Apache Software Foundation and chief scientist at eBuilt, Inc.
He is a founder of several open-source software projects (including Apache httpd), architect of the current Hypertext Transfer Protocol (HTTP/1.1), and co-author of the Internet standards for HTTP and Uniform Resource Identifiers (URI). He received his Ph.D. in Information and Computer Science at the University of California, Irvine.
There is a popup link that says:
The waka protocol is designed to be a replacement for HTTP as the primary application-level protocol for the transfer of hypermedia information over the Web. It is based on the same architectural principles as HTTP/1.1, but without the baggage of preexisting syntax restrictions. Waka has a tokenized, self-descriptive syntax for communicating multiple asynchronous data streams over a single transport connection. This talk provides an introduction to the waka protocol and insights to its eventual impact on the Web Architecture.
Sounds impressive to me, does anyone else know more?
What I want to know is this; what is going to replace http? The article really doesn't say other than alluding to p2p as the way of the future.
Now, I may agree that p2p will be way cool as its uses are just barely beginning to be explored but I don't think we will see http disappear any time soon. I wouldn't be surprised if five years from now things are essentially the same as they are now in this respect and http is still a staple of many things web related.
And this;
Why? If you make a request and it takes you that long to respond... your clients will search for a different source for the data. How many customers do websites lose for loading slow in the first place? You might as well use snailmail for that kind of stuff.
So... mod me down if you must but somebody please explain what Box is talking about here.
Prospecting Stinks. Stop Wasting Time on Cold Calling.
As Bruce Schneier says, the cutting edge is always moving, but the low-end is here to stay.
Old standards have a way of hanging on, even when there are superior replacements. Look at all the strange, vestigial crap in PC hardware. Look at NTSC video, 8.3 filenames. You'd be amazed how many large companies keep important data in VSAM files instead of real databases. People might start using new standards for new applications, but the old standards will still cling in the old applications or eveb in new applications that must interact with old ones.
Are there exceptions where old technology was phased quickly? Sure. The cost of change can be high, and business people generally want technology that is Good Enough rather than following the latest and greates trends just for their own sake.
You should see the old tech that is still used in the finantial sector. In these parts, the rule of thumb is "If it ain't broke, don't fix it." When you are dealing with people's money (and government regulations therof), the cost of botching a change is very high.
--mkb
I've never heard Don Box described as just a .Net engineer. That'd be like calling Richard W. Stevens just a "C programmer."
/. is with the Windows world.
Thanks for the laugh. It's always good to be reminded just how out of touch
"Linux can only win."
I always love this statement. I've been hearing it what? For the past 8 years or so.
But even though I keep hearing it over and over and over again, it still hasn't come any closer to reality.
The way I see it is that you have fell victim to your own big delusion.
"So we have this great idea where we'll set up cops on the streets to look for people carrying VCRs. That'll stop anyone from being bad. If you want to walk on the street, you'll need a licence from us, but we'll do it cheaply..."
It'd be laughable except there are enough morons out there to believe that poor security in Outlook is somehow the fault of TCP/IP.
Xix.
"Everything is adjustable, provided you have the right tools"
On the desktop it is beginning
I think you ought to double check your numbers. Linux is nowhere near #2 on servers, or #1 on embedded systems... unless you severely limit your definition of those markets.
link
Webserver machines, Linux being second with 29% share: link
Domains hosted: Linux being number one with 35%/30%: link
Can you post any statistic where Linux is not second on servers?
Damn, those links didn't work:
l l
http://www.netcraft.com/Survey/index-200007.htm
http://www.netcraft.com/Survey/index-200106.htm
The web server marketshare is important, but not a leading indicator of the total server market share.
As far as the reports showing tremendous growth of Linux in the server market, these only come from IDC. Both Gartner and Goldman Sachs have published numbers which dramatically dispute the IDC figures.
In the case of both Gartner and Goldman Sachs, they established their numbers by random surveys of corporate purchases. The IDC numbers are apparently "estimated" from Linksys CD shipments, ftp downloads and a variety of other questionable sources.
It's also interesting to note that all reporting of IDC numbers are from 1999 and 2000, whereas the Gartner and Goldman Sachs surveys were done in 2001. If nothing else this indicates that Linux is not a growing market.
As far as the embedded market, Wind River's VxWorks is still the dominant player, with Linux having only a small niche in comparison.
Put up or shut up.
Er, yes I agree, it was frustratingly short on detail. Now is that Don Box or some ZDNet hack's fault?
The article is vauge, non-technical and vacous, but having read things that Don Box has written, I seriously doubt that the fault lies with him.
My Karma: ran over your Dogma
StrawberryFrog
MS loses, says Screw this, and drops JVM based on lawsuit result, and stops J++ tool development
.NET version. It just is not ready yet and will be called J#. Of course it is .NET rather than Java, but the tool itself continued in a different form.
Well, according to Microsoft, they are working on a
LedgerSMB: Open source Accounting/ERP
No, because it really does take a guru to understand the complexity that is microsoft these days.
"Unix guru" has come to mean "that guy who sits on his ass all day reading Slashdot and logs into the server once a month at 1 am from his dialup at home to fix an obscure problem -- and all he probly did was cut and paste the error message into google to find the solution or maybe typed 'apt get blah' "
we need a way to moderate the moderations as "funny"
Sounds like the Microsoft I know. Clueless bullshit used to destroy a usefull tool so that they can puch adverts over the new broadcast media. Pull is what makes the internet work. Push is what M$ wants. No thanks, next.
Friends don't help friends install M$ junk.