Cart
[Home] [By Thread] [By Date] [Recent Entries]
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > -----Original Message----- > From: Paul Prescod [mailto:paul@p...] > Sent: 01 March 2002 19:08 > To: xml-dev@l... > Subject: Re: HTTPEctomy considered bad (was RE: RE: > MS thinks HTTP Needs Replacing???) > > > Bill de hÓra wrote: > > > > > > > > > > But HTTP is not a transport protocol (though you can use it > > > that way). It is an application protocol, with a set of > > > generic semantics. > > > > No doubt. You will see the HTTP/SMTP-TCP/IP layers flattened in > > the future for better or worse. > > I don't believe that, but we'll see. > > > ... A transport is somewhat relative. As > > Sean points out that has consequences if you expect messaging > > behaviour to remain consistent across what can be characterized > > as "transport soup". From the application's standpoint what it > > really wants are service or policy guarantees for message > > sending; > how that > > is realised isn't that interesting to it. > > TCP is the layer that gives policy guarantees for message > sending. It's the *transport*. HTTP is the layer that adds > application semantics. If the application doesn't care about > those semantics then it gets no benefit from HTTP other than > firewall avoidance. This is simple enough. When I specify for example a policy, I specify a type or a pattern. If HTTP can be determined to fit into that type then HTTP is fine for my needs. I don't need to specify HTTP explicitly. I may specify HTTP explicitly as a mnemonic for my policy needs because that knowledge is baked in. > Applications can choose not to care how bits move from place > to place. But they cannot ignore the question of where the > bits live, under what names. That's what application > protocols like HTTP and SMTP are about. I didn't understand this. I can write code that depends on HTTP without knowing it. > I don't think that anybody claimed that we're at the end of > science. HTTP is a starting point, not and ending point. The > problem is that start with what we've learned from HTTP. It > starts from scratch reinventing a layer *below* HTTP. So HTTP stays at the top of the stack. Sounds absolute enough. Can't see that panning out though, even if it was a good idea. > > ... The issue with abstracting over HTTP is more strategic than > > technological: if you pull that abstraction off, you > commoditize web > > infrastructure. Not at all unlike, say, the way hardware > makers were > > commoditized by proprietary operating systems. > > I don't understand what you are saying. It sounds interesting > but I don't understand it. How does SOAP "commoditize web > infrastructure." How much more "commoditized" could web > infrastructure become? You can buy it by the inch already. Simple enough. As the language provider of choice you can dictate terms. HTTP dictates terms to those who build the software the web runs on. It is a monopoly of sorts, albeit in the public domain. Language matters and computing platforms are linguistic entities. In the long run, infrastructure is forced to accommodate language, not vice versa. HTTP is just one example. At the point where computers connect with problems we're in the language design business; I think pretty much everyone on this list, of all places, understands this at some level. New languages will be built and deployed that abstract over HTTP. Old languages will evolve to cater for changes in the environment. If a language arises that becomes a platform of choice for intercommunicating, people will not program to HTTP anymore, they won't need to; and this is most important, even if that language itself depends on HTTP. SOAP is one such example; I think you will see developers increasingly program applications directly to SOAP, rather than HTTP. Microsoft and IBM among many others fully expect this to be the case. I don't say that this is good or bad, just that is highly likely. Bill de hÓra -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.4 iQA/AwUBPIDb/+aWiFwg2CH4EQIaHACgrXEME9QJZMdx/8gRisKWWKVdlwEAoM3m L93nMy2JUfsj0m5cm+5HREW/ =vPZl -----END PGP SIGNATURE-----
|
