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-
The link is wrong in the post...but somehow it still works??
Anyways.... "...HTTP presents a major challenge for Web services, for peer-to-peer applications and even for security..."
Ok...so don't use peer-to-peer applications via HTTP?
A sentence later...
"A replacement will eventually have to be found, he said, but it is not at all clear who will provide this replacement. "
An industry-wide protocol "does not work for Microsoft" so it must be replaced.
Sadly, they will probably remove native HTTP support from their OS in the future so no one has a choice but to use their own proprietary protocol (yes, I realize they didn't cite a replacement, but who else can see it coming? It's not like they haven't done this before...try accessing www.msn.com with old netscape).
-kwishot
And..... with what is Microsoft proposing to Embrace/Extend/Engulf it? I mean.... they wouldn't be saying anything like this if they had no interest in replacing it with something....um... proprietary? Can you imagine how cool it would be? Now Micro$oft has a copyright on MSFT (Multimedia Streaming and File Transfer protocol, incidentally it's also their Nasdaq code :-) ) and so the browser war is finally over. The Web server war, also, is finally over. Peace at last.
Vacuum cleaners suck. Kings rule.
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
Because the client can send arbitrary multi-part MIME data in POST requests. 'Nuff said.
FTP anyone?
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.
Well, one of the reasons why I think HTTP will stay around is because it is NOT peer to peer. One of the nice things about centralizing, especially in the case of the web, is that you keep all of your business logic on that location. That means if you want to easily change things, you can do so. With P2P if you have a distributed model, you would have to worry about getting all of your changes replicated out... that could be very prone to error!
I admit http has its downfalls, but I don't think it is going away any time soon!
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
Aren't all thing's days numbered? I mean I think most would agree that it's unlikely we'll be using HTTP in 2070, right? That's like 24820 days away. There's a number for ya.
From the article: "If it takes three minutes for a response, it is not really HTTP any more," Box said. 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. What do the intermediaries care. It's just packets. They don't care how long it takes for the response.
-- This is not a sig
Title: Microsoft guru: Stamp out HTTP
Isn't "Microsoft guru" something of an oxymoron?
--Chag
"If it takes three minutes for a response, it is not really HTTP any more," - What the hell is he trying to do that takes so long???
"A replacement will eventually have to be found, he said, but it is not at all clear who will provide this replacement." - Id say from that that Microsoft allready HAVE a replacement in mind and are first trying to tell us we actualy need one
"If people can't search the Web they call the IT department, so the IT department makes sure HTTP is always working. We have engineered the hell out of it."
M$ Engineered the hell out of http????
No one got beat up more often than the mimes of the old west!
There needs to be a built in content rating standard that binds webmasters to law. Actually, this would be easier to implement with IPv6 since you could effectively segment subnets without too much of a problem (i.e. - put pr0n on designated IPs, educational on others, etc).
There is too much dangerous stuff out there to just be turning kids loose. One might look to Microsoft and all their money for help implementing this but who are they to create standards?
Life is the leading cause of death in America.
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
.. that M$ is up to something. I know it.. my ears are burning.
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.
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
"If it takes three minutes for a response, it is not really HTTP any more,"
If it takes 3 minutes or as stated later 5 days, the problem is not in the protocol, but the architecture and performance of the application.
The beauty of HTTP is that it is generally stateless, that is, you can use it, come back 5 days later and pick up exactly where you left off without consuming any resources. A lot of programmers have done things to get around this, but really as a matter of convenience, rarely for architectural reasons.
I'll believe this when I see it, P2P is a great technology, but the web is just inherently different. I don't see where this guy is coming from... comments?
Open source software is the real cockroach of the internet. It's everywhere and no matter what MS does they can't seem to stamp it out. After the holocust the only softwhere left will be open source, since no one will be able to find the single copy of closed source software locked in some dead corporate vault somewhere.
-jj-
But isn't "Microsoft Guru" an oxymoron?
Well, the funny thing about this is that all the .NET web service stuff uses SOAP (XML) to communicate through HTTP (presumably for both ease-of-use and so that webservices can be used in places with restrictive firewalls, for good or ill). Now, this guy is undoubtably aware of this fact, but coming from that knowledge, it's interesting to note that Microsoft's .NET team:
.NET webservices onto the protocol (not that i've heard anything about shortcomings-- it's been a couple months since i've worked with .NET at all).
a) Bases their web services on communication via HTTP then
b) Says HTTP is doomed because it's not peer to peer
Maybe someone made a bad choice for their protocol and is trying to cover his ass? I doubt it. Maybe they're trying to shift blame for any shortcomings of
Or maybe this guy has a point, which i doubt, but i'm far from qualified to really judge.
ben.c
Microsoft must have run out of ideas on its "how to swamp out a market segment" list. This smacks of the way they used to do things: reinvent/rename the wheel just so they can claim control in their "new" proprietary format. Bah...this one is ignorant and will fail mightily. So I guess I should be happy..
.NET is a year behind development, so I wouldn't worry much.
It's Don Box.Now I know that he may be largely unknown outside the COM/Windows world, i.e. he is a nobody to the /. crowd, but he is an acknowledged guru in component technologies (COm, .NET, etc) and not even bothering to name him is ridiculous.
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.
http has been designed to serve a special purpose, and is the optimal solution to this problem. It's ascii, it's fast, it's compact etc. And most important of all: It's a standard not controlled by a single company.
.net will provide, is a proprietary solution on which other proprietary user interfaces can be built, and these user interfaces can then exist over a network.
.net won't either.
.net solution, then have a look at the OLE2 "hello world" application source code.
What
There are many network oriented user interface protocols: X11, Citrix, Microsoft RDP, VNC are just a few of them. But none of these can replace http, and
If you want to know how complexity is, when a webpage is replaced with a
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
What?!?! Dominating the world of crappy operating systems isn't enough? Now M$ is going to try to work its way into our open protocols too. I seem to remember the internet being designed with the goal of being completely open and non-proprietary (*cough* completely against all of M$'s goals).
Can we say subscription-ware to the extreme?
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
AMEN!
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!
Why does that sound like a generic argument to me ? :)
....
.... said HTTP (Microsoft, DMCA, random issue) presents a major challenge for Web services, for peer-to-peer applications and even for security. A replacement will eventually have to be found, he said, but it is not at all clear who will provide this replacement.
"One of the big challenges facing Web services (Security, Freedom of speech) is our reliance on HTTP (Microsoft, Patents)," said Box (rms,...). However, there is nothing wrong with HTTP (Microsoft, Patents) per se,
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.
Earth to Microsoft: use SMTP! How about your beloved SOAP over SMTP, even!
The trouble with all these established protocols is that it's too late for our friends in Redmond to proprietary-ize them.
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.
Changing to P2P will only make sense when everyone becomes a contributor to the web. But that's not the case now, and will probably not be the case in the future. Distributed content environments (like the icq personal frontpage, or how do they call it) are/always will be less reliable (uptime, virus free, etc...) than centralised and well maintained servers.
StarTrek.org Free Webmail
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!
can they make it so we can be arrested for using the standard for purposes that are competetive (or maybe disrespecting) to MS? that would be the way-coolest.
And even though Microsoft is working on the problem too, Box did say that Microsoft is unlikely to succeed alone.
oh, nevermind...it's a team effort. nothing to worry about ;-)
although you can argue that Napster wasn't really peer-to-peer.
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.
i love the browser, but some pages just dont like following the newest standards..
im not saying that standards is always the exact right way to go.. but they do help! (now if only there were more following them..)
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.
- "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."
So...refreshing.The problem with HTTP is that it is stateless and requires a constant connnection (or a state-tracking mechanism with repolling or push-back). This becomes a problem when dealing with web services that process large or time-consumming transactions before returning results. HTTP connections timeout. But, protocols such as SMTP, for example, don't require synchronious connectivity.
This is why I love SOAP/SOAP::Lite. It allows me to use firewall-piercing HTTP as a transport protocol, but it also allows me to use
- HTTP/HTTPS
- FTP
- SMTP
- TCP (straight up)
- POP3
- Jabber
- and so on...
When HTTP is dead, CPAN will have the replacement module ready to go. (BTW, props to Paul Kulchenko!)-- @rjamestaylor on Ello
OK, Microsoft obviously is saying this because they can't control it. Anything that Microsoft doesn't have its control-freak-claws into is obsolete, right? Heck they tried to convince everyone that MP3's are obsolete, and it seems to me it took away very little (if any) of its use. Just because Microsoft says something doesn't mean that it is what they say it is. I *YAWN* when I read microsoft says this or that about whatever; they don't know any better and aren't changing my development patterns.
This is how MS is trying to control the internet, they could careless about the desktop market now. If they control and own the underlying means which allow for communication over the internet, we are all doomed.
READ BETWEEN the lines, fellow geeks. What he's really saying is "HTTP is a cludge, .NET is much better. Use .NET"
;)
Seriously, i'm sure Microsoft would love to replace HTTP with something "better." Sounds like further "embrace and extend" to me. It was not enough for them to make browsing the web with anything other than IE a hellacious experience, now they want to overtake the very protocols on which the www runs. If they are successfull... well, i hope you all are familiar with how to use a "gopher" client.
In my experience, when Microsoft say's, "We want to make it better," they usually mean, "We want to control it."
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.
"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."
.doc format, to give us this interoperable format? Suuuuure.
Melt the internet? What the fuck is he talking about? Nice sounding metaphor, if a bit meaningless. As for ways to do long-running requests, I fail to see how a stateful connection in this case is anymore beneficial than a dated message sent via a stateless protocol to a service. In fact, questions about uptime, data transmission integrity, and security have me thinking the stateless message is better.
Adapting for P2P
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. 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. "It's all hackery, it's all ad-hoc and none of it is interoperable," he added.
Correction. Programmers are not creating hacks to get around the limitations of the protocol, they're creating hacks that misuse the protocol. It's all hackery? This coming from the land of Patches? Simply amazing. None of its interoperable? Are we to expect Microsoft, the company that gave us the
This is nothing but FUD.
All your httpds are belong to us!!
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.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
I guess Microsoft needs to think outside the box.
The Virtual Bookcase: book reviews
suck my penis, willie.
Ok, I am a programmer and I have written some RPC functions / services / insertBuzzWordHere for some of my employers. The thing that I fail to see is the fundamental difference between P2P and (as the author calls them) RPCish services, like HTTP.
I understand the complaint that RPCish services lacks a suffecient TTL to really make them an application, but is P2P really nothing more than a RPC with a TTL->infunity? Or is there something else that Im not seeing here.
It seems to me that having a function on node A that calls an RPC function on node B, then B returns the results at its leisure with an RPC call to node A. This could feesibly use RPC to acheive a P2P-style connection. Is there something like this already? From what I hear, this seems to be what SOAP covers, but I have never investigated this. Any thoughts, rants, info would help out. Thanx.
Please give your mod points to others, Im at the cap. They will appreciate it more
Power Corrupts the Best
by Michael Bakunin (1867)
The State is nothing else but this domination and exploitation regularised
and systemised. We shall attempt to demonstrate it by examining the
consequence of the government of the masses of the people by a minority,
at first as intelligent and as devoted as you like, in an ideal State,
founded on a free contract.
Suppose the government to be confined only to the best citizens. At
first these citizens are privileged not by right, but by fact. They
have been elected by the people because they are the most intelligent,
clever, wise, and courageous and devoted. Taken from the mass of the
citizens, who are regarded as all equal, they do not yet form a class
apart, but a group of men privileged only by nature and for that reason
singled out for election by the people. Their number is necessarily
very limited, for in all times and countries the number of men endowed
with qualities so remarkable that they automatically command the
unanimous respect of a nation is, as experience teaches us, very small.
Therefore, under pain of making a bad choice, the people will always
be forced to choose its rulers from amongst them.
Here, then, is society divided into two categories, if not yet to say
two classes, of which one, composed of the immense majority of the
citizens, submits freely to the government of its elected leaders, the
other, formed of a small number of privileged natures, recognised and
accepted as such by the people, and charged by them to govern them.
Dependent on popular election, they are at first distinguished from the
mass of the citizens only by the very qualities which recommended them
to their choice and are naturally, the most devoted and useful of all.
They do not yet assume to themselves any privilege, any particular right,
except that of exercising, insofar as the people wish it, the special
functions with which they have been charged. For the rest, by their
manner of life, by the conditions and means of their existence, they do
not separate themselves in any way from all the others, so that a perfect
equality continues to reign among all. Can this equality be long maintained?
We claim that it cannot and nothing is easier to prove it.
Nothing is more dangerous for man's private morality than the habit of
command. The best man, the most intelligent, disinterested, generous,
pure, will infallibly and always be spoiled at this trade. Two sentiments
inherent in power never fail to produce this demoralisation; they are:
contempt for the masses and the overestimation of one's own merits.
"The masses" a man says to himself, " recognising their incapacity to
govern on their own account, have elected me their chief. By that act
they have publicly proclaimed their inferiority and my superiority. Among
this crowd of men, recognising hardly any equals of myself, I am alone
capable of directing public affairs. The people have need of me; they
cannot do without my services, while I, on the contrary, can get along
all right by myself; they, therefore, must obey me for their own security,
and in condescending to obey them, I am doing them a good turn.
Is there not something in all that to make a man lose his head and his
heart as well, and become mad with pride? It is thus that power and
the habit of command become for even the most intelligent and virtuous
men, a source of aberration, both intellectual and moral.
Insert anti-Microsoft rant here.
I don't even bother anymore.
The "intermediaries" only talk IP, they don't parse the TCP or HTTP. IP is stateless - you've no idea when you route/switch a packet if it's from a pre-exsiting connection or a new one as you only look at the source and destination IPs. It's irrelevant if the "intermediaries" have low TCP/HTTP timeouts set because you're not talking TCP/HTTP to those devices. As long as the 'net is still passing traffic the TCP connection will never time out between the browser and the server - as long as the user doesn't hit "stop" - because TCP sends keepalives.
Either the
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.
I don't fear HTTP going away; it was never really intended to do what we're doing with it.
But what I do fear is Microsoft's ideas for a replacement. P2P? Sure. But imagine the control and insidious design they would want. If we replace HTTP, we cannot let Microsoft set the new standard.
I, for one, welcome our new Antichrist overlord.
Hmmm, I say we're screwed if Micro$oft succeeds with this. I mean, they're already attempting to "own" the world. This would be just another step to their world domniation.. There should be NO corporate company developing a protocol, it should be done by the user. Due to the fact that if it's created by the company, chances are it won't be properley done, so that other people can compete.
This is kinda the doom for the internet..
Free means no restrictions, ironic the FSF's GPL forces restrictions, isn't it? What's your definition of free?
I rememeber when active directory was out..it was the killer as microsoft put it to internet traffic. Now look at Active Directory...? are you or do you know someone who actively implements it?
We all knew that M$ was really pushing .NET with a new marketing campaign. We have read all the wonderful .NET snake oil masqueraiding as "legitimate journalism", even on slashdot.
It is wonderful to see Box tout anonymous services over the web (hmm, isn't SOAP part of NET?) as the downfall of static pages.
But what was HTTP for? Delivery of content in static pages. This is NOT anonymous services. It is not stateful or transactional. And it shouldn't be. The fact that people have figured out all sorts of ways to add state - fine - its grafted on top of a simple protocol with a simple implementation and low computational and bandwidth requirements.
In the Halloween document, they stated very clearly that They wanted to control the protocols. How else can you get your cut unless you have licensed out proprietary protocols?
If I had a pie for every Microsoft evangelist... I'd have a lot of pies.
Mm
/\/\icro/\/\uncher
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."
CD's will be taken over by DVD
DVDs are already obsolete aren't they?
Since legacy stuff moves on and new stuff transitions in 100% right off the bat...he's probably right!
Galego
Que Deus te de em dobro o que me desejas
[May God give you double that which you wish for me]
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*&#%&#.
Do we really have to lie about what people say in order to stimulate conversation? Mr. Box never said that HTTP was doomed. On the contrary, he said it will outlive all other protocols. He suggested that a higher level abstraction sit on top of HTTP to allow longer running interactions, he DID NOT suggest that HTTP was dead, dying, sick, or in any way obsolete.
Get a life!!!!!!!!!!!!!!!!!!!
Once again MSFT tries to sell us "services" - this year the PHB buzzword is "web services". And since MSFT is losing sales - because people are cutting back - they need to find a "reason" why PHBs should go for "web services".
One way is to tell them HTML is dead.
We in the Open Source sphere know that we can ignore all the MSFT FUD and just keep evolving along. Let MSFT tell us Borland is dead (they grew more than MSFT last year due to Open Source). Let MSFT tell us that Linux is dead on servers (we grew more than them on servers). Let MSFT tell us that Java is dead (it's beating the MSFT competition six ways to Sunday).
Face it, only one thing smells like Dead Fish, and that's the Dark Lord in Redmond.
One Web Service to Rule Them All
One Web Service to BIND Them
One Web Service to SSH Them All
And in the darkness blind them
-
--- Will in Seattle - What are you doing to fight the War?
If it tames three minutes for a response I doubt you would have many users.
Doug Alcorn
Comment removed based on user account deletion
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.
Duh. Why the *#@$ would you do that over ANY interactive protocol anyway?
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.
Ok, He's right. HTTP's old and cumbersome for dyamic webpages... And who's web page is monolithic anymore (other than Geocities tripe like "heres my doggie named Barkie" ). Auction sites need fast updating info. News-posting sites need quick updates...
Now, what about using FTP for what it was meant for... File Transfer Protocol. I see no reason to embed all the non-text links to a ftp. Mainly, I'm talking about binary executables(zip/exe/gz), large images (50k or bigger) and such. FTP's allow connection control, bandwidth control, and user discrimination(r/w for updates of page admin). FTP's are easier to control, update, and admin. It would be nice to see FTP and SSH have a reunion, but It seems that computers wouldnt have enough resources to do this and handle large amounts of users. The last is just is guess, since I figure that ssh ftp has easily been done (pipe 21 through ssh). Any ideas on the feasibility of ssh FTP with large amounts of users?
Still, the big Idea is why P2P? Most networks kill broadcast packets, but there's a great use for them. There's big corps like Akamai that handle huge amounts of bandwidth control... CNN, Fox, and other sites upload streaming video and audio. Big news events, those sites were flooded. Why? If systems were set up right, 1 connection could serve hundereds of users. They'd just have to tune to the next broadcast, or watch the 'already started' broadcast.
My idea is the technology is ALREADY HERE. IPv6 is right around the corner, and we need it. IPv6 records on dns is an issue (2 standards that are non-compatible), however free standards people (read opensource'ers) will standarise this problem.
Don't forget that MS is JUST A COMPANY who wants to make money. If they have an OPEN STANDARD, I'll listen.
Screw moderation, just post responses. It's not like moderation means anything.
Josh Crawley
http is dead - M$ .Net comes out to conquer the internet - woot
coldfusion is dead - M$ frontpage extensions show up everywhere with javascript
C, java, perl, python, etc... are dead - Everything is now coded with M$ C# or nothing
(sarcasm - for those that dont understand)
Ave Molech Setting
Strictly speaking, sans the MS spin, I think we can all agree that HTTP is overused.
.NET will have a built-in P2P app/browser. Add $100 bucks to the office price tag.
T K
Trying to build web apps that keep state, etc is a complete pain. Just try avoiding javascript because of different DOMs, and you'll wind up with alot of missing functionality. Then you have to use cookies, and hack up convoluted solutions for a simple problem.
People don't like cookies, they don't like javascript (stupid hack, mostly used for pop-up hell) and again, different browsers make dynamic content a real bitch.
What we need is the equivalent of the browser for web servcies (stupid catch-phrase). Whatever you want to call it, we need a client-server app that provides P2P services. I think MS wants to dominate another market by introducing another "browser" (the P2P app to end all p2p apps) only this time, they'll get their foot out the door before anyone like Netscape can compete.
They fumbled with the browser and wound up having to give it away. I have a feeling that Office
Didn't they buy groove networks? Just change the protocol it operates on.
Either way, someones going to have to punch a hole in the firewall, we cant just keeping using port 80. Web servers are for http pages. Real-time apps need another port, their own dedicated servers. Not Apache 2.2.13+modssl+PHP+mYSQL+dotNET+MP3+mod_Mono+mod_G
The article goes to indicate that the golden HTTP protocol can't do everything, and as such, its days are numbered.
True, HTTP can't push a full gamut of services on the web. It wasn't designed to do that. That's is where the HT in HTTP becomes most significant (HyperText).
What is ultimately the problem is the push to get the browser to do everything, including handling your applications (think ASPs) and transactions (e-commerce in particular). This mentality of "the browser must be able to do everything" has become its own monster, relying on a protocol that was really designed to push little more than web pages.
There is very little that browsers can't do these days. However, you can bet that over 99% of all web browser activity uses HTTP (which isn't necessarily a suitable protocol to do everything)...
Now, there is plenty of room for other protocols to come in and enhance the web. However, HTTP still has a large role and shouldn't be called dead prematurely. However, if these new protocols were to remain proprietary, you can bet that they will never be as widely accepted as HTTP (which is not proprietary, btw).
He is not advocating using P2P for everything, merely that a more full-featured protocol would have P2P functionality in it, along with some other features that he mentioned. HTTP will certainly stay here for browsing, I don't see it going away anytime soon, but HTTP2 or whatever you choose to call it will be a lot more suited for today's uses.
Please subscribe to see the more insightful version of th
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.
PREACH, BROTHER, PREACH.
It is time Alan Cocks and Richard Stoolman tied the knot.
- The BOFH Troll
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....
It would be foolish to trade HTTP's known limitations accumulated through decades with P2P unknown dangers, simply because we could. HTTP does its job well.
KingPrad
Stop the Slashdot Effect! Don't read the articles!
As the next gen of firewalls start tearing apart the HTTP stream looking for encoded application level stuff, you're going to see a marked decrease in performance of the tunnelling, again. This race for further and further tunnelling will make it v. inefficient.
New killer apps will have their own methods and resort to HTTP encapsulation only when unavoidable. One or more of these killers will reach a suitable critical mass that firewall holes are demanded by senior execs.
Thus HTTP will exist as the standard encapsulation for those apps not yet worthy, and the others will get their access.
Next to go is the strict adherence to TCP over IP for internal networking [RTP,something else over IPv6], and possibly a switch back to old school Token Bus on Ethernet for some segments.
Note: conjecture warning
[% slash_sig_val.text %]
"a Microsoft .Net engineer declares HTTP's days are numbered" This just goes to show that .Net engineer's have a high use of narcotics.
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
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
NOT.
They know that eventually IIS will lose. How do they make that a non issue? They redesign their^H^H Internet, so that the other products wont be used either. When they try this move there will be a new anti-trust law suit.
Get a free ipod.
Newsflash! Josh Crawley, a noted expert on .. .. announced today that moderation is useless and that Slashdot should immediately change their model and rewrite Slashcode! More at 11.
We have to do something to make it (HTTP) less important," said Box. "If we rely on HTTP we will melt the Internet.
Almost seems like he feels that the HTTP protocol is overweight and that it's putting strain on the Internet. If you're comparing HTTP protocol to SOAP wouldn't that be like Ricki Lake calling Oprah Fat?
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.
...sounds like OpenSource
Last Paragraph
"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"
what about not having Vendors work on anything and let those who remember the good old days of low level protocol work do it. You know. Experience. Open source. More trusted. The last thing we need is IBM, Microsoft and others beefing up a protocol to use Digital Copyright Enforcement
I know what dis lame story needs... some PAGE WIDENING WOO HOO!!
"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?
Just because some Microsoft engineer says HTTP days are numbered doesn't mean it is. Again, they're just doing PR stints.
I'd hate to say it, but I strensously doubt what this person has to say will change anything.
My two cents. . .
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.
You think I really care about moderation? What's it give me? Absolutely jack shit.... and jack left town. The only reason why I said dont mod me up in favor of resonding is that you can do only 1 or the other.
Hell, you wont even put a name to your post.
Actually there is a need for this type of protocol to support applications talking with applications on different computers, otherwise known as web services. SOAP addresses this and Microsoft's .NET goo simply takes this approach. Their marketing department has "hyjacked" the whole purpose of XML (SOAP is a XML schema) as their own. Typical for large corporations.
.NET v.s. ___.
We now enter the era of XML schema wars, which is essentially a "data format" battle. i.e. XML based Word v.s. XML based PDF.
It's clear that there are enough companies and people out in the world who won't choose Microsoft goo of the week, leaving the practicality of effective open and vendor neutral standards a reality.
What Microsoft does is completely irrelevant since there are various alternative systems evolving. Simply ignore Microsoft and implement your solutions as YOU see fit adopting whatever standards you find appropiate. A beautiful aspect of reality is that anybody can create their own "world view", shared with others or not, within the framework reality. This is especially true in computing. If people find your "world view" or "system" more valuable and more useful than someone else's, they will adopt it. Evolution in action.
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.
Sure both have flaws. But they are so entrenched, they'll never be displodged.
Seriously, MS would never adopt RMI though, and RMI has it's own problems that makes it not viable for large-scale internet/P2P connectivity. I know .NET has their own non-HTTP protocol called "remoting" that you can use to bundle web services together without using HTTP but I don't know how viable it is for wide-scale communications on the Internet, it's recommended for LAN use. But MS may try to extend .NET remoting as the next-gen protocol.
But I have to agree that everybody building P2P applications on top of web services will soon run into a wall due to HTTP's stateless nature.
At Ubero we built our own wire protocol, DCTP (distributed computing transport protocol) that suits our needs very well and allows us to extend it as we need to.
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.
HTTP is not obsolete. Microsoft is saying that HTTP doesn't work for what THEY want the net to be, or should I say .NET?
.NET won't work with HTTP? It might be sub-optimal, but then again, you must have previously made the decision to addopt .NET.
They will go something like this on the near future:
"See, we have Win2k + IIS that can do XYZ. Sadly, your current choices, Linux + Apache, only support HTTP. Buy from us what we say it's good and none is going to get hurt".
If there are so many things wrong with HTTP, why Microsoft itself is using it, and supporting? I thought that when you realize that a technology is bad, you try to replace it. Not from one instant to another, and ironically/timely, at the same time you are about to launch a product that, while in theory works fine with HTTP, works better with a protocol designed by who? Who?
Yep, you guessed, Microsoft. Or do you thing that
Conversion of technologies, with MS controlling. I heard this talk a long time ago, thanks...
Also, at the bottom of the article, Don Box says, to legitimize MS actions, that W3C or (insert random organization) is also thinking like MS is... Whatever, because like he said "MS to succed alone".
Yep, main point back, it's not for the healthy of the Internet, but for Microsoft.
Nice wrong way of doing business.
Buy a Nintendo DS Lite
Of course HTTP is dead! All I type in now to get to a site is WWW...
If P2P has a technical meaning beyond 'networking apps where each end is both client and server' then it is all about providing workarounds for the hurdles that exist because of firewalls, NAT, IPV4, dynamic IP, roaming user, asymmetric connections, etc. Designing network applications for use over HTTP transport that can't deal with it being high latency, mostly asymmetric, stateless at the transport level and not providing IPv6 services is just committing to broken design, nothing more. Trying to do a marketing pirouette to make it sound like that design is so innovative it requires a new internet infrastructure is a nice try at a coverup for bad design/planning.
On a very simplistic level it seems that the http protocol is:
What - path/object in URL
Where - host:port
hoW - method (get, put, post...)
Perhaps we need another three W's:
Who - public keys
When - expiry date
Why - in response to X
The who, when, and why could be used at the network border to allow authorized responses to travel through at some later date. This may resolve the issues identified.
Just my $0.02then I think they should. Microsoft seems to often be very critical of anything they don't sell, however, and http was being used to serve web pages while MS was still in Windows 3.11, were they not?
And I do understand the protocols evolve and emerge, so again if they have some ideas, they should develop, offer, and advance - it's not as if they don't have a few R&D dollars.
Of course, most that probably glanced at the article thought it meant that one will no longer have to see http:// in the address bar.
He's right if he's implying P2P is the future. If you want to keep the net open and "free", support open protocols like JXTA (http://jxta.org), not proprietary Microsoft protocols.
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.
... would we switch protocols from a set standard that works just fine, and not switch to a decent operating system?
So much for the "change isn't good" argument by M$.
"And we have seen and do testify that the Father sent the Son to be the Savior of the World"
1 John 4:14
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.
Maybe I am reading into the article a little bit, but I think what he is talking about is a protocol that would do something similar to what you are talking about. Sure, you could write an application that makes an RPC call over HTTP and then the "server" responds by making an RPC call back to the "client". But having that happen at the protocol level, and having it be an accepted standard would be a lot better for interoperability between various platforms and languages. SOAP is limited by the protocol it is running on top of. When you make a call over HTTP, the response is sent back through the same connection.
.... it is not http anymore. That's right - it's http running on IIS. fuck you M$, XML-RPC will eat your lunch, and you've been asking for it for some time now. Go shove that in your .NOT
Again, with emphasis on the inadvertant Freudian slip:
I'm sure they meant "break the dependence on HTTP" (which, for applications that don't fit HTTP's model but are using it anyway, that's a good thing). But saying "Microsoft has some ideas on how to break independence" is just beautiful. :-)
--JoeProgram Intellivision!
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
Who gives a rats about Don Box. He is one huge M$ schill and almost purely reponsible for the messy SOAP protocol. The Fact of the matter is that XML-RPC did everyting that SOAP does but did it in a manner that WAS more efficient. The comes along M$, IBM and Don Box and decides that we need this stuff modeled in such a way that it is easier to produce COM hooks. SOAP was designed with one thing an one thing only in mind, M$. OS programmers where continually bitching about it during the RFC development process but that stuff was just thrown aside. Hell Don Box told us Open Source developers to shutup and he would address the issues (Yea Right) . SOAP is horribly inefficent and SLOW in comparison to XML-RPC. Where I work this is why we are sticking with our XML-RPC implementations and will not touch SOAP with a 10 ft pole.
Got Code?
"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.
"It's all hackery, it's all ad-hoc and none of it is interoperable," he added.
Every protocol they have ever come up with is a hodge-podge of non-interoperable, often inoperable, ad-hoc junk.
Take a look at SMB (aka CIFS), for instance: it consists of at least 3 different incompatbile sub-protocols, breaks every network coding rule you could possibly learn in college (network stack abstraction is one, word alignment issues are another) and generally has more exceptions than rules.
So you see, the world will be much prettier if MS designs an inoperable protocol to replace the operable HTTP
Comment removed based on user account deletion
Opera kicks ass. On my mac here at work, it loads the 200-comment-long nested-view slashdot threads in a fraction of the time InternetExplorer5 does. I keep IE open for doing actual work though; it's kind of handy having a seperate browser history for work-related and non-work-related web browsing.
__
Choose mnemonic identifiers. If you can't remember what mnemonic means, you've got a problem. - Larry Wall
"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.
Excerpt from article:
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,"
I don't know about you, but I don't want anyone "initiating an exchange" with my machine. I'll do the initiating thank you.
Sig free since 2/6/2002
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?
Don't forget that the main reason behind .NET is that it will save Microsoft even if it is forced to be divided into separate smaller companies, because it is making Microsoft Office software more dependent on the Microsoft Windows and on it's servers and softwares for Internet, i.e, it is serving as a 'glue' for all MS softwares.
.NET on Linux is very bad for the Free Software Community, because MS holds patents for this plataform, and if someday they make Linux users dependent on .NET plataform, then it will be possible for them to charge royalties in the future.
Also, I think
Do you think a company this large, with this vast amount of money, would be stupid or good? No, they are evil, they just want to LOOK stupid. Just remember how they dominated the OS market, first making the IBM computer users dependent on DOS, and then charging for it.
it doesn't matter what excuse microsoft uses to proclaim HTTP dead, microsoft will simply proclaim it. By that time, microsoft internet software, like internet explorer and internet information server, will have already quietly been enabled with MS-WWW-P which is, of course, prorietary, secret, DMCA protected, etc.,etc. When Bill throws the switch, all non-microsoft web entities will cease to function. At least as far as all of the microsoft-only lemmings can tell.
W3C refuses to give Bill the keys to the Net? Make W3C irrelevant. Make a new net. Make an ALL-MS-IE-IIS-ALL-THE-TIME net. Why not? From Bill's point of view, are there really any other players? Why waste a lot of time with standards? Look how well its working with MS-Office...
It might be a good thing... The rest of us will suddenly live in what we've been striving for all along -- a microsoft-free net. At least until Microsoft buys cisco...
Is anyone else surprised that ZDnet has the com.com URL? I thought NSI kept all those. Maybe they offered up the right price.
Th
McArhtur
"If people can't search the Web they call the IT department, so the IT department makes sure HTTP is always working. We have engineered the hell out of it."
Well, um...the answer to this is actually no. When they call us, the users normally have a problem with DHCP or a corrupted TCP/IP stack if they're running some version of Windows. I can't recall http ever being broken. I've had entire machines crash, a router go down, and of course leased lines die before but the protocol break? No. I've seen things not configured properly but the protocol did not break.
HTTP works for what it was designed to do. It was to be a simple protocol meant for quick transfers of TEXT. Client machine makes a request. Server responds. Connection ends. How many companies actually run an FTP server anymore? For MS, the Windows update runs completely on HTTP and scans your computer to see what you have installed. Their FTP server contains almost nothing and you must download patches via HTTP.
I'm all for another protocol to do all the interactive content. This also scares me though cause I'm thinking of Oracle's dream of Internet Appliances and someone else owning all the software and you do subscriptionware. I don't mind subcribing to a website like books24x7 or oreilly but subcribing to my software? And someone else holding my data? No. This sounds like another ploy to do that. And let me guess, it will work best on WebTV.
What I don't want to see is the MS weed mentality touching a new protocol during its infancy. Or... then I think about it and wonder what life would be like if MS would take all its windows users to their MSN and we can have the internet back. I kinda like that idea.
...scares me, it's what Crazy Bill does. Innovation vs. Strategy...one thing leads to another.
I want to be alone with the sandwich
Well this then implies that all of MS' server products will be obsolete as they are not peering with the computers in the traditional 'client' role. Be careful also because this smells stinky... if MS is pushing p2p uber alles, then this being up the point of if you use .NET are then therefore required to serve up content for others against your will/ without your knowledge? This is really the larger implication of client/server being obsolete, isnt it?
I was sure this would be a prime subject for the "BSD is dying" guy to update his spiel with. It seems not. Ah well, you don't need to be Kreskin to predict that "BSD is dying" trolling is dying, I suppose :-)
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
I'm amazed I didn't see a million posts about www.freenet.org. Freenet is a distributed, encrypted data sharing network that makes use of a web browser and proxy to allow you to browse all of freenet from your local node. Plus you can post data anonymously onto the network without requiring DNS. Something ICANN is sure to love.
Oh, and your web browsing experience could very easily be protected under the DMCA from corporate/government spying, since its encrypted.
.NET is the next .COM bubble
They're not quite doing the same thing, so it's hard to draw a direct comparison, but if you've read the BEEP specs it should be pretty easy to see the differences by reading the XATP draft. If anything, it might make more sense to look at a flavour of BEEP running over XATP.
If your interested in following this up in more detail, please feel free to join the spec-dev@xatp.org list.
If I ever have to use a url that says "MStp://slashdot.org/" instead of "http://slashdot.org/", I'll never use the known World Wide Web again.
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?
HTTP is the primary protocol for the world-wide web
C'mon, what's happened with slashdot?????
Seems reasonable to me...
Acquiescence leads to obliteration
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.
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. 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. "It's all hackery, it's all ad-hoc and none of it is interoperable," he added.
one is passive! That is just fine with me. I don't need the websites I visit to COME to me. I thought the "push-model" died a long time ago. I get enough spam already, now they want to move that from the email client to the browser? No thanks. And again, MSZDNET has no clue what they are talking about. Did David Coursey write that piece? Forgot to look.
Okay, to me this is a response to management...http is not the internet. There already a host of standard protocols. HTTP sits on top of TCP/IP. Don't worry about it...they're just trying to get you to think there's a problem. There's not. HTTP is convenient and powerful, and everyone knows it. But, it's not the internet. When MS starts advertising the New Internet, just remember: you read it here first. If you need new services, just have your admins open up a new port on the firewall. If they won't, you don't need it anyway.
-- An image is worth about 2.5E4 characters.
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
READ
READ AGAIN
NO REALLY, GO BACK AND READ AGAIN
Maybe somewhere around there you will see that the post you're replying to didn't say anything about web browsers.
.... everything would be peer to peer - including your private information
If you cannot keep politics out of your moderation remove yourself from the Mod Lottery.. NOW!
There's some interesting related work here on REST (Representational State Transfer):
http://internet.conveyor.com/RESTwiki/moin.cgi
This is an architectural style for building web services, etc. that may be more appropriate for HTTP than how XML-RPC and SOAP are typically used. If I understand it, the claim is not that XML-RPC and SOAP are fundamentally flawed, but that they are often used in a way that doesn't take full advantage of the power of HTTP.
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.
I remember back when we tried using p2p in the ealry days. Not everything is suitable for P2P
Especially not gaming. doom without a centraized server is not a good thing (2 people geting the same item at the same time, etc...)
anyways, server based sites are MUCH better. Crackers would have a field day with small peices of data that could be manipulated each time it was sent to another comp.
maybe i just have the concept wrong but i think it holds alot of security risks
We seldom regret saying too little but often regret saying too much.
The biggest problem I have making a good web developer is most MS types tend to design-think using a client/server mentality. It's no wonder the brain trust at MS believes HTTP sucks. They don't yet build anything near a truly large systems, and haven't yet learned what it takes to do so.
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?
> the client can give no feedback about it
> other than unexpectedly closing the connection
Bah! The client can simply issue a new request refering to the active transcation. It can ask the server for anything it needs, even a "graceful", server initiated, shutown of the "push" data stream.
> no prioritization or unsolicited messages
> are possible.
Why not? I can push a multi-part data stream and have javascript pull it apart. Been there, done that, have the T-shirt. Each message unit is just a packet of arbitrary data.
BTW, what is an "unsolicited message"? Doesn't a client need to know how to deal with all its possible inputs? I mean, I don't know many real time quote and news streaming clients that could handle an unsolicited "Dear Mom, Today's been a hard day..." e-mail thrown into their data stream.
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 only major difference is you got to see much of the process as it grew up in the public eye. Do you really think a "standard" is better when 50-100 people sit in a room and ask those questions, comming up with only those few ideas they are capable of at the time?
I think not. All that is the standard "web", HTTP and all, has grown up in a standard setting process that was far, far, healther than most.
Should be "slowly *lose* favor." One of my Favorite Fuckups (TM). "Lose" is the opposite of win; "loose" is the condition of your bowels after eating cheap Mexican food. Just so you know.
Starting to sound like .NET is "embrace and extend UUCP"
Architecture changes over time, what is "right" for today becomes "wrong" for tommorow.
When client-server architecture was right, there was more bandwidth considerations, and various other problems that prevented peer-to-peer from becoming a viable architechure until now.
Without computer security, there would be no hackers.
What happens when UDP 6, 7, and 22 are lost?
It may be old, but a good deal of thinking went into both TCP/IP and UDP/IP. Why waste your time trying to reinvent them until you've taken some time to learn them?
BTW, TCP isn't resource inconsiderate. A packet to say "hi", a few acks to let the sender toss data it won't ever have to retransmit, and a packet to say "bye". Shocking, simply horrible.
Have a problem you would like resolved?t ate/corp_level_BSA.htm.
Can't locate your "party member"?
Look in the green pages under <Government services *see Microsoft* Contact your legal representative in the Microsoft alumni listings.
Or visit "us" on the web at: http/www.microsoft.gov/services/representatives/s
*Gotta love a company that just CAN'T let a day pass without trying to violate yet another anti-trust law*!
George B.: Yes Bill, that was a fine "donation" you made to the patriot act, but that was yesterday's anti-trust fines! What'll you buy for me TODAY Bill?
206.39.38.2, DDN-BLK-36, DOD NET INFO CENTER. 800.365.3642 206.36.0.0-206.39.255.255 NET RANGE.
slashdot posting apache releases and what not. how come i dont see anyone b.itching about how this shouldn't have been posted? the most useless garble ever. how many m$ employees talk to the press and end up in the paper... i'm surprised its not like Dr Whackjob Joe "microsoft is responsible for 9/11"
mannnnnnn
Haha! You're deluding yourself. Microsoft does not have a 10-20 year plan.
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.
...where hambuger eaters from microsoft are sadly mistaken.
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.
Where is anyone in the article implying Microsoft is the solution to this? Where does anyone in the article express interest in eliminating HTTP?
This article is about breaking the dependance on HTTP for all tasks. There are places where HTTP makes a lot of sense, and places where it doesn't. The main goal expressed was to develop a standardized protocol to use when HTTP doesn't make sense. (e.g. p2p support, transactions that take extended periods of time)
Quotes from the article (emphasis mine): (please note that Box is the Microsoft engineer being interviewed)
---
Box likes to think of HTTP as the "cockroach of the Internet" because "after the holocaust it will be the only protocol left standing."
---
---
"One of the big challenges facing Web services is our reliance on HTTP," said Box. 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, he added.
---
---
"We have to do something to make it (HTTP) less important," said Box.
---
Note he did not express any desire to elimite HTTP.
---
Several working groups are working on the problem at the W3C, the organisation responsible for Web standards. And even though Microsoft is working on the problem too, Box did say that Microsoft is unlikely to succeed alone.
---
Therefore if anyone is going to try to "scuttle" anything (which is not what this article suggests, see above), it is going to be a group effort, not tied solely to any one vendor.
---
"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."
---
slashdot!=valid HTML
Freenet is a free p2p transfer protocol used for webpages. Although for me it is dirt slow, isn't this what Box is describing. Every machine both a server and a browser.
The difference between object oriented programming like .net and streamed programming like http, is that a webserver can start sending the html web page via http before it has completed calculating the web page. http does not need random access, whereas .net classes do.
.net comes up with anything as stable as http. By then, replacing http will be unthinkable.
.net api based web servers do we have today?
Random access to properties and methods is one of the basic foundations for classes.
Some would complain that http is ascii. Well, all e-mails are sent as ascii. In order to send national characters like æøåéüñ, you can use MIME encoding. Unicode can also be embedded in 8 bit character streams. Ascii is good, because it's easy to debug, easy to troubleshoot.
http has been tested for many years. Many webservers out there still don't conform 100% to the standard (like not allowing HEAD requests for instance), and if you want a truly idenpendent standard, it will take lots of years before
The most optimal technology seldom wins. But the technology that first gets widespread, often does. How many http servers have we got today? How many
.net is useful, but not as a http replacement.
Dybdahl.
M.Sc.E.E. in networking
'nuff said.
Put up or shut up.
Lets just look at this from the correct perspective:
1: P2P developers could use any protocol they like there are many to choose from, hell invent another if you like
2. Most sensibl;e P2P developers choose http not because of what it is or does but because it passes through firewalls, thus P2P clients/servers can talk to the outside world!
3. There for the problem is a security issue. i.e. use a protocol taht traverses security!
4. Microsoft are partly to blame for the proliferation of firwalls in organisations, and in many ways here are suffering from there own past actions and mistakes
5. If microssoft and or anyone else come up with a new protocol, I.T managers and security staff will take a long time to open the gates into the corporate network to anything new!!
6. Therefore microsoft (and everyone else for that matter) need to clean up their security before this would ever be accepted. It looks like We will all just have to deal with building layers on HTTP me thinks..
Linux Has successed. You are blinded by microsoft.
Linux is a free, stable powerfull platform maybe we (as linux users) don't want to eat up the internet with a 90% *monopoly*. But if 90% of people with a computer would be linux people then we would have failed. Keep the internet free, diferent, helpfull and it a success.
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
Boo hoo! I'm a poor little linux fan boy who can't stand it when my overly optimistic predictions of linux destroying Microsoft don't come true.
I think I'll go make myself feel better by trolling slashdot.
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
Don Box is not really " a MS.NET engineer". .NET intro in chicago).
He's the guy behing DevelopMentor.
He's an ex C++/Unix guy who uses EMACS. (He admitted it at the
Check out http://www.donbox.com
Hahahahahahahahahahahahahahahahahaha...
not as long as there are stupid people with homepages...
(this web site is brought to you by the commands ctrl-c and ctrl-v)
RA7
-
"Consistency is the hobgoblin of small minds" - RWE
"If it takes three minutes for a response, it is not really HTTP any more,"
;)
Is this in reference to IIS?
Spelling nazis: I know referring is misspelled above. It is misspelled in the HTTP protocol too.
This is the Internet. You can say "fuck" here. - AC
Waka has not yet been released in specification form due to the economy sucking away all of my free time, and that talk never happened because ApacheCon 2001 Europe was cancelled. I did get a lot of work done on it during my vacation just prior to 9/11.
I recently changed jobs and am now chief scientist at Day Software. My protocol work will get back on track soon and I will be able to introduce waka at ApacheCon 2002.
However, I should note that Don Box (whom I know from UCI) is mistaken in his complaints. HTTP is not an RPC (SOAP is, but SOAP is not and never will be part of the HTTP standard). HTTP has included an asynchronous completion mechanism since 1994 (see the 202 Accepted response). I have no idea why folks at Microsoft can't read the specification of HTTP and make use of the protocol as it was designed to be used.
I have plenty of reasons to replace HTTP with a better protocol, but none of them involve making the Web act like a DCOM service, which is simply a bad architecture for the Internet.
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.