Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Generality of HTTP
 Gavin Thomas Nicol wrote: > >... > > This is probably true. I also think that a lot of people claiming > great things for HTTP are claiming more than it was intended for... HTTP is the protocol designed to support the Web. According to Tim B-L, the "Web's major goal was to be a shared information space through which people and machines could communicate." How much more scope could we attribute to HTTP than that? But really, I don't see the point of the Web anthropology. The Web exists. It is incredibly successful. There is no doubt that Stone Soup effect is a big part of that. I also claim that a couple of key design decisions were central. One is to have a single, unified address space for all information. If that's the case, what are the implications for web services? What does SOAP have to say about a single, unified address space for all information? > and fail to see that HTTP+a set of application/URI-space semantics > isn't the same as HTTP itself. That's another semantic game of little relevance. Can XML be used to encode any data structure? Is a purchase order a data structure? Can I define an XML vocabulary for purchase orders? If I do so, am I applying a layer of semantics on top of XML? Am I still using XML? Can XML be used for purchase orders? Yes. Can HTTP be used for peer-to-peer communications? Or asynch communications? Or reliable communications? Yes. In exactly the same sense. Is it a good idea for XML to be used purchase orders? That's an engineering question. It takes thought, effort and discussion to decide. Is it a good idea to use HTTP for peer-to-peer or asynch communication? Ditto. It doesn't do to merely wave the hands and claim that HTTP wasn't designed for these things. HTTP was designed to be a general purpose data sharing protocol, as XML was designed to be a general purpose data structuring protocol. >... > I find an ironic example of when I've been guilty of something > similar. Many moons ago, I tried to get rid of the URL-encoding > bogosity on GET submissions from forms, because from an I18N > perspective (and for other reasons), it is abhorrent at best. HTTP did > (and last time I looked still did, though I'm fuzzy on HTTP 1.1 now) > support an entity body. My thought was to use that instead... as you > could make it I18N safe etc. > > I was told, in no uncertain terms that "HTTP doesn't do that", > "servers don't do that", "even though it's allowed, it's not correct > usage", etc. I think saying that HTTP can do broadcast is roughly akin > to this. I don't see the analogy at all. If I understand the suggestion then I would object to it not on the basis of any detail of the implementation of HTTP but on the fact that it violates web architecture as I understand it. GET takes a URI because HTTP is address-centric. If you move the data into the entity body instead of the URI then you are moving to an FTP model. Plus, you might as well use POST. > > How is it mediocre? Now that I'm coming to understand it, I think > > it's brilliant. > > Don't confuse the original HTTP with what you see you can do with it. What is the relevance of this "original HTTP"? HTTP was re-designed from the ground up. I'm talking about HTTP of today. Paul Prescod 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
