[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: HTTPEctomy considered bad (was RE: RE: MS thin

  • To: <xml-dev@l...>
  • Subject: RE: HTTPEctomy considered bad (was RE: RE: MS thinks HTTP Needs Replacing???)
  • From: Bill de hÓra <dehora@e...>
  • Date: Sat, 2 Mar 2002 14:06:25 -0000
  • Importance: Normal
  • In-reply-to: <3C7FD196.4CA30F40@p...>

ms thin
 
-----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-----


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.