OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] MS thinks HTTP Needs Replacing???

[ Lists Home | Date Index | Thread Index ]


> -----Original Message-----
> From: Mike Champion [mailto:mc@xegesis.org]
> Sent: 26 February 2002 17:09
> To: xml-dev@lists.xml.org
> Subject: [xml-dev] MS thinks HTTP Needs Replacing???
> 
[...]
> Among the problems with HTTP, said Box, is the fact that it is a Remote 
> Procedure Call (RPC) protocol; something that one program (such as a 
> browser) uses to request a service from another program located in 
> another computer (the server) in a network without having to understand 
> network details.

Hmmm...

Fielding: "HTTP is not RPC"
http://www1.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_5_2

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

Why does something stop 'being' HTTP just because it takes a long time to 
get a response? What about persistent connections? What about HTTP Events 
(don't have reference to hand)?

"...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 get 
the result for five days."

Er. Asynchronous messaging?

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

It's not clear its worth the trouble anyway!

So the process is: build a whole pile of stuff on top of an existing architecture, 
but don't play to that architectures advantages. Blame the architecture for not 
conforming. Define new architecture.

This would be fine, IFF, the requirements had changed. Personally I don't see 
anything in web services that requires new technologies, or fundamental reworkings 
other than the possibility to make someone a lot of money.

L.




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS