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

Comments

Well Duh...

[pridkett]

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

What about things that P2P doesn't make sense for

[Hoarke42]

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?

He's got a point

[wiredog]

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.

Re:He's got a point

[Anonymous Coward]

Put the data you need to track in a database table or two and use hidden form vars to build the query to grab what you want.... Instant serverside cookies... No muss... Just another fscking query....

What the title _should_ read:

[PureFiction]

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

the declaration has been made

[qqtortqq]

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.

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

NAT & Firewalls

[mikeee]

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

Re:NAT & Firewalls

[mikeee]

If you don't have a real, static IP, no, you aren't really on the internet.

If you are behind a firewall that only allows HTTP, no. If it only allows outgoing connections, not really. All you can do is what HTTP can do, which is much less than IP can.

It would be really sad if the net were reduced to the web. "You say you need IP connectivity? Are you some kind of hacker?"

Re:NAT & Firewalls

[GSloop]

Yeah, let me run and open every port to every caller! I guess I was completely crazy to close off all those ports and limit connections for any and every service...

[Sheesh] Security and Convience will ALWAYS play off against each other. If you have locks on your house, you're not really getting the full benefit of a house!? Sure, locks make life more "inconvenient." But you trade some convenience for security. I close off all those ports because I don't know what might be used to exploit the openings.

Now, we'll get to arguing about packet filtering vs. proxy filtering and how proxies are better...blah blah blah.

In short, I want a BALANCE of convenience and security. Blocking some content (ports/hosts) is a way to do that. That's a good thing in a system that's setup right. Does your company let anyone into the building that wants to get in, and only disallow those that it activly sees doing mischief? No (at least for your sake I hope) they don't. They say, do you have some purpose here? Are you explicitly allowed. Then you get in.

Frankly you can argue about NAT and unblocked connections all you want. What my clients want is functionality. The functionality of the network is compromised by too open a security (too much functionality) of the internet. They want the machines to work, the data to get processed, and to spend as little money as possible fighting battles. The solution is only to open that which needs to be open to acomplish the business objectives.

Cheers!

HTTP workarounds

[ciole]

There is work going on to address the shortcomings of HTTP...

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 .NET propaganda (the buzzword that will not die) i've been imagining a world without HTTP for a while. It's pretty much a given that i'll be able to brag to my grandkids about having used HTTP. So what will the world's computing resources look like then? The "internet" was not neighborhood-pervasive until HTTP - where and when will the next major transition occur? And (god forbid) will it be ".NET"?

What's left out of the ZDNet article is ...

[feelafel]

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

Good points

[hondo77]

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.

A new FUD campaign, I swear

[mfarah]

Box likes to think of HTTP as the "cockroach of the Internet" because "after the holocaust it will be the only protocol left standing."

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.

Re:A new FUD campaign, I swear

[abulafia]

Sorry, I have to disagree on a number of points.

Actually, ftp is a lousy protocol for transfering files. It requires a persistent connection between transfers, uses a bunch of connections anyway, isn't designed for machine-machine interaction, and doesn't have a mechanism for content type information. HTTP is a "transfer" protocol, and there's nothing in particular that relates to hypertext in it.

Content type information would be useful, you're right. Requiring a persistent connection, that can be good or bad, depending on the nature of the file transfer. It is true that for requesting arbitrary files meant to be accessible by anyone, the protocol has inefficiencies. You didn't note the problems it causes for firewalls, but I'll throw that in anyway. FTP is still the most efficient means of transferring files.

http is exactly what it is named - Hypertext Transport Protocol. People are abusing it (for reasons of expediency) to do a lot of things it was never meant to do.

HTTP is fine for P2P applications, in general; it's not hard to have a program the both makes and accepts HTTP requests.

I would argue that http is a stupid protocol to use for P2P. The only reason it is used is because firewalls leave that port open. One might as well argue (with substantially more reason) that port 22 and the ssh protocol is fine for P2P. Honestly, were that the case, a lot of the problems inherent in deployed P2P apps would not exist.

HTTP is suitable for delayed responses, although the entity expecting an eventual response will have to be running an HTTP server. Of course, if you want to get a delayed response, you'll have to have somewhere to accept an incoming connection, whether it's a mail server, an HTTP server, or some weird new MS thing.

RPC over http is a bad hack. RPC, for all the problems it has, has been running over TCP/IP for quite some time now... the _only_ reason to encapsulate it is to circumvent firewalls. Yes, RPC has a multitude of problems, and honestly, I hate it. Encapsulating it to hide from security restrictions does not make it any more appealing. Users might not like a requirement to tunnel legitimate services through a firewall, but that is how it _should_ happen. There are a bundle of add-ons to make RPC over http appealing, like XML "standards", etc, but none of those are inherent to doing RPC over http.

HTTP is not suitable for is negotiation, since you can't easily go back and forth multiple times (later interactions are not sufficently tightly connected to not need to send all of the information again). Of course, this is essentially what people are trying to use it for.

Here, we agree. http is for random file access with built in intelligence about file types. Nothing more.

-j

not so sure about that...

[Narcocide]

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.

Re:not so sure about that...

[dkemist]

You still have to conceed the point that http evolved to where it is today, and if one had to design something from scratch, it would likely be far different.

I mean, let's take a connection oriented protocol like TCP and add a text based stateless protocol on top of it. Ok, that makes sense so far.... but wait, we want to be able to maintain state, so lets introduce this new concept called "cookies" and we'll use ASCII strings to identify things. And, it would be nice to be able to make multiple requests per TCP session, so let's put together some keep-alive mechanism. Ohh, and I want to be able to talk to multiple servers on a given IP, so let's add a host header field.... But wait, all of this is transmitted in clear text! Let's engineer a set of encyrption protocols to stick between our HTTP layer and our TCP layer. Here we'll solve some of the same engineering problems, like adding an SSL session ID to maintain state. Now, instead of requesting simple documents, how about we design an extensible markup spec to request "web services?" Yeah, that should work.

It is a testament to the design of the protocol that it's still ticking with all these enhancements (aka hacks.) But, all the layers add bits of overhead that could likely be engineered out if one had the luxury of starting from scratch.

I'm Glad to Hear this from Microsoft

[elliotj]

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.

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 .NET team at Microsoft is listening to this guy.

doh!

[mikeee]

Using TCP is a shortcut, and lazy.

Until you end up reimplementing half of it on top of UDP. Badly. And yes, I've seen this multiple times.

Enough with the NIH, please? There are many years of effort in the common TCP stacks, and many subtle things they do right that you'll miss the first dozen implementations.

For the love of god, if you need a substancial subset of TCP's features, and can live with the overhead, use TCP!

HTTP Info

[Joe U]

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.

Insert negative Microsoft subject here

[Anonymous Coward]

Insert anti-Microsoft rant here.

I don't even bother anymore.

The "Cockroach"

[gcondon]

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

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

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.

Stateful vs. stateless

[Salamander]

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.

Considerations for long duration

[Christopher Bibbs]

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.

problems with microsoft + HTTP

[cballowe]

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?

It has begun

[pergamon]

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.

It's called BATCH PROCESSING

[Anonymous Coward]

Duh. Why the *#@$ would you do that over ANY interactive protocol anyway?

He has a point

[underpaidISPtech]

Strictly speaking, sans the MS spin, I think we can all agree that HTTP is overused.

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 .NET will have a built-in P2P app/browser. Add $100 bucks to the office price tag.

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_GT K

What nonsense

[rseuhs]

Next, let's discuss Microsoft realizing that .NET is a "stupid idea." Microsoft doesn't care about setting up a scapegoat because they're 100% sure it will work, and they're probably right. The whole company has been restructured to work with .NET and it is not going away. Latest copy of Windows in development is Windows.NET, latest set of development tools is Visual Studio.NET, latest certification is MCSD.NET. Getting a trend here yet?

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:

.NET is essentially just the next incompatible-to-everything-but-itself Win32API with some Java-ideas and pseudo-language-independence thrown in.

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.

.NET is nothing new, it's just the next API Microsoft *HAS* to push, otherwise nobody upgrades. And it could be Microsoft's biggest mistake if it runs on Linux.

Re:What nonsense

[rseuhs]

XML, SOAP, DHTML etc. are not core parts. (And XML allows binary sections which means that you can put *everything* no matter how incompatible into an XML, BTW)

The important thing is the API which will be incompatible to everything else. If it isn't it would be very bad for Microsoft.

I suspect that .NET is incompatible to everything else, but projects like Mono could endanger this incompatibility and become big problems for Microsoft.

Linux can only win. Worst case is that everything stays as incompatible as it is now, best case is that .NET becomes multi-platform which would kill Windows in a few years.

The reality will probably be something in between: Compatibility will be better than current Wine/Win32 compatibility, but not 100% - yet Linux could make big inroads also on desktops if Windows-compatibility is good enough.

The way I see it is that Bill Gates and Steve Ballmer fell victim to a big delusion: That Windows could survive on a leveled playing-field.

Re:What nonsense

[erasmus_]

I really like your optimism, but I think that as you point out, reality does not include Windows being killed off "in a few years." Nor do I understand why it necessarily has to die? I think most people would agree that competition is good for markets, and OS market is no different. I do not want to see one clear victor, but rather have Linux make significant inroads and have these 2 OSs and all their associated technologies push each other to become better. Even though I realize it's a different business model, I think even Linux could risk stagnation with nothing to complete with.

http == qwerty

[peter303]

Sure both have flaws. But they are so entrenched, they'll never be displodged.

P2P over HTTP was to bypass firewalls

[addikt10]

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

Protocols never die

[metoc]

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.

Re:Yeah, but

[ctembreull]

> For them to go their own way is not completely unexpected.

You're mostly right. It was *totally* expected. It's pretty much a given that MS only supported Java contingent upon:

their ability to get away with embrace-and-extend

their inability to come up with something different

Once either or both of those conditions were no longer valid, MS had no reason whatsoever to support Java. After all, they "hate" Sun almost as much as Sun "hates" them. The more conspiracy-minded might state that MS supported Java only as a means to an end: draw it out, make it ubiquitous (which they did) and then leave it to die with no support on Microsoft's monopoly platform. Java without MS can almost certainly not survive. And, those same conspiracy-minded people would quite likely be right.

Microsoft doesn't make knee-jerk decisions. EVERYTHING they do is calculated to produce a given set of results, whether that be to curry good will, give plausible deniability in the event of a lawsuit, extend their already-prodigious monopoly, or squash a competitor like a slow-moving insect. .NET is designed to do all of the above. It makes them look good 'cos they're trying to make stuff run for everyone everywhere "regardless of platform". It gives them another "But we're just innovating" card to play in court. It will eat Sun's bottom line for breakfast. And it will lock 95% of the world's computer users into a solution which they cannot get out of without discarding EVERY MS product they own and adopting Linux.

When you look at it this way, it doesn't really matter so much *what* .NET is. What matters more is what .NET will do. Looks like all those checks to politicians were well-spent, Mr. Gates. You just bought yourself a remodeled, tacitly legal monopoly to abuse.

Re:Yeah, but

[saintlupus]

HTTP is old and needs to be replaced, as soon as we can figure out what the best replacement is.

Er, why? Am I not being advertised to in the most efficient, flashy manner?

Fuck, the majority of what I use the web for could be handled by Gopher, let alone this fancy pants HTTP protocol.

--saint

Oh sure, HTTP's obsolete

[rnturn]

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.