Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Generality of HTTP
 > I wouldn't. But it's one thing to say that HTTP, along with lots of > supporting infrastructure, I tried to stay away from saying "lots". It doesn't need lots. It's mostly there already. > can do all sorts of interesting stuff, > quite another to say that HTTP was designed for them or that it's > optimal or even adequate. There are things HTTP isn't suitable for, but there are less things that REST isn't suitable for. For example, HTTP doesn't do a great job at streaming, but another protocol obeying the constraints of REST could. > > The architectural style used to craft HTTP is certainly capable of a > > lot more than what HTTP can currently do. So you'd need extensions > > for some things > > Then it's not HTTP any more. When I use a new media type, is it still HTTP? Of course. HTTP supports extensibility on many levels; content formats, transfer encodings, headers, methods, status codes, etc.. To say that using these extensions is no longer HTTP, is incorrect. > > (though not, I believe, for the example you describe above). > > Disconnected operation (whether deliberate or accidental) and > endpoint mobility are the tricky cases. It can be done, but it's not > pretty. A local proxy could, if there's a disconnect, queue the request and return a 202 (Accepted) to the client, thereby informing the client that the result of the invocation will be returned later. In the body of the 202, the proxy could return its own URI that represents the completion of the invocation. Endpoint mobility, if I understand you correctly, isn't tough. As HTTP is a state transfer protocol, bringing an endpoint up to state with another just means transferring state between endpoints. This can be done with a GET from one to the other (web server on the "client"), or a PUT in the other direction (where each is likely to be a compound document, or perhaps just pipelined) - depends what you need. > Other protocols (or hybrids, HTTP+SMTP to name only the most > obvious example) do a better job. I'd have to see it to know. > > Consider what might be possible with vanilla HTTP 1.1 and; > > - a web server near the user (such as in the browser, ala KnowNow) > > - intermediaries adding value with queueing, caching, filtering, > > routing, etc.. > > All sorts of things certainly. But I don't see how you get from there > to any kind of interesting or useful generality claim for HTTP. HTTP > can be layered on top of SMTP, and IP can be layered on top of fleets > of carrier pigeons: does that mean that SMTP is more fundamental than > HTTP or pigeons more fundamental that IP? HTTP is more general. It can submit data like SMTP, with POST. It can retrieve information like POP3 with GET. It can store files like FTP with PUT. This is not an accident. Shall we take this one offline too? 8-) It's surely off topic by now. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@p... http://www.markbaker.ca http://www.planetfred.com 
|
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
|
|||||||||
