- From: Paul Prescod <paul@prescod.net>
- Date: Mon, 18 Mar 2002 16:30:29 -0800
- To: www-tag@w3.org
David Orchard wrote: > >... > > Noah and I share the viewpoint that protocol evolution is a good and natural > thing. My reason is because I don't think that the everything that we want > to do in the future should be modeled as propagation of a shared information > space. For example, the assumptions of cardinalities of identified > resources might not hold. Adn the propagation issues may be different > depending upon the application. A concrete example that I like is thinking > about reliable delivery of a stock quote message. From the queue software's > perspective, this is a POST. But from the stock quote applications > perspective, this is a GET. So I want to POST a GET request ;-). Wait, let's drill down on this because I think we need to think more about examples like this. You talk about stock quote delivery but how could that be a GET? Do you mean reliable stock quote request? If so, how much more reliable could a request get then doing a GET with a digital signature. You know for a fact whether you got the information you asked for or not. If the application wishes not to deal with retry it can delegate responsibility to retry to a local agent which behaves as a standard HTTP proxy. The only thing that would be special about this proxy is that it retries when a GET fails. Now let's say that the stock quote message is actually an event sent from the server to the client as per HTTPEvents. In that case it is a POST. And once again a retry-ing intermediary could be a standard HTTP proxy. Now let's presume for a second that I'm wrong. Presume that the intermediaries really do need to do some kind of address space rewriting etc. I can imagine that for some applications. Does it hurt anything that the entire address space is flat? Does it hurt anything that the client COULD directly address the stock quote server but chooses not to? You would only POST a GET if you had a good reason to do so and if so, what's the problem with doing it? A particular application could choose not to avail itself of the global namespace -- as long as we don't create specifications that deny the application access to the global namespace. > Perhaps the real issue isn't http, but whether a shared information space is > the way that we should think about future applications that we want to > build. The information isn't really globally shared because of security boundaries. I think the question is whether the *address space* is shared. If you separate information spaces using security mechanisms then you can choose at any time to give someone a key to get in. If you use separate address spaces then you have to use bridges. Bridges are very expensive and as far as I know have no advantages. Remember the days when you could pay extra money for a compiler that would make DOS memory segments go away? There are some companies that advertise themselves as bridges between web services address spaces already. I think that in the long run they'll be like DOS compiler vendors... Paul Prescod
Received on Monday, 18 March 2002 19:34:02 UTC