Re: section 1, intro, for review

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