[
Lists Home |
Date Index |
Thread Index
]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> -----Original Message-----
> From: Paul Prescod [mailto:paul@prescod.net]
> Sent: 01 March 2002 19:08
> To: xml-dev@lists.xml.org
> Subject: Re: [xml-dev] HTTPEctomy considered bad (was RE: RE:
> [xml-dev] 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-----
|
