Re: section 1, intro, for review

Paul:

With respect, I think you're reasoning from the converse.  I hear you to 
say: 

* many, many things are well modeled by REST (true)
* perhaps the very counter-example David gave is a bad one 
  and could be handled by REST (possibly true)
* lots of folks are out there doing ugly things they shouldn't,
  including failing to use URI's for addressing, and probably
  failing to apply REST where it might have advantages
  (true)

I don't think that proves that a shared memory (REST) is the right model 
for all the resources we may reasonable want to integrate into the web. At 
best it leaves the question open.

Furthermore, I think we need to admit that even when REST is applied, 
there are two different sorts of cases.  I would compare these to 
Load/Store into the memory of a computer, and Load/Store into the I/O 
space. 

I can generally store into the memory of a computer, or into the memory of 
the web (e.g. PUTing an html document)  I can then do a load (Get) from 
the same address (URI) and retrieve what I put in.   There's not much else 
to say about it.  A pure memory.

An I/O bus is trickier.  At one level, it looks like the memory: 
Load/Store.   However, if I store into the right location in the I/O 
space, magic happens.  The CD ROM drive spins faster.  Maybe if I load 
from the same location I get back in indicator of the new speed, or maybe 
not.  Modeling the disk controller as load/store, I get to use lots of 
hardware and software mechanisms that are common with the real memory 
example.  That's why we try to use REST where we reasonably can on the 
web;  common abstractions, shared implementation mechanisms, and to some 
degree we can reason about the persistent state of the web.  BUT:  in 
another sense, there's something very different going on with the CDROM. 
The semantically interesting specification for the spinning disk is not 
"load/store", it's "Set speed", "Seek", "Eject", or whatever. Behavior is 
encoded in the addresses.    This is very, very different from a world of 
shared memories or web documents.

I think this teaches us that when REST is used to manage memory-like 
resources on the web, we can get by with that one level of description. 
When REST is used for other resources, the higher level semantics are at 
best tunneled through a  Load/Store abstraction.  Sometimes that tunneling 
is worth doing, sometimes it's better to admit that the resource is not 
memory-like, and use a protocol more directly appropriate to the resource. 
 I think we should at least leave that option open in the web 
architecture. 

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







Paul Prescod <paul@prescod.net>
Sent by: www-tag-request@w3.org
03/18/2002 07:43 PM

 
        To:     www-tag@w3.org
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        Re: section 1, intro, for review


David Orchard wrote:
> 
> ....
> 
> So I find it not suprising at all that changing one variable (adding
> extensible data interchange models via XML) means a change to a 
different
> variable (adding different information models to a single information
> model). 

What do you mean by different information models? From my point of view,
the Web has one fundamental universal feature and that is the URI. The
question that faces us, in my opinion, is whether there should be
alternate addresing models. For instance if I go to XMethods, I note
that every web service there has its own addressing model.

The ATM location database accepts zip codes and produces ATM locations.
None of its ATM locations are universally addressable because they don't
have URIs. 

Kazoo accepts phone numbers and produces XML person records. None of its
person records are universally addressable because they don't have URIs.

GeoPinpoint accepts IP addresses and returns locations. None of its
results are ...

(geez, ignore REST for a second, what ever happened to privacy!)

Now can anyone make a case that these applications are richer or better
because they invented proprietary address spaces? Under what
circumstances is a proprietary address space an advantage?

 Paul Prescod

Received on Monday, 18 March 2002 20:19:47 UTC