RE: New AFTF draft.

Hmm.  I don't think we can have it both ways.  If resources don't travel, 
then it's incoherent to say "this resource lives at server X".  In other 
words, if something has a location, then it's necessarily reasonable to 
say that it has a location that moves, at least in a system like this. 
Keep in mind that with my earlier example, there was on picture of my on 
any server.  The only state representing the picture at all was in the 
message.  So, I think we can have it two ways:

1) Resources don't travel because they are never localized.  They are just 
abstractions with no notion of location or proximity.  In this case, 
Henrik's proposal that resources don't travel makes sense.

2) Resources do or often do have a location.  In this case, I think it's 
as coherent to say the location is in a message as on a server.   I hope 
we aren't tieing the notion of URI and resource to client/server?

Thanks.

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







"Henrik Frystyk Nielsen" <henrikn@microsoft.com>
Sent by: xml-dist-app-request@w3.org
09/11/02 12:32 PM

 
        To:     "Jean-Jacques Moreau" <moreau@crf.canon.fr>, "John J. Barton" 
<John_Barton@hpl.hp.com>
        cc:     "David Orchard" <dorchard@bea.com>, "Christopher B Ferris" 
<chrisfer@us.ibm.com>, "Carine Bournez" <carine@w3.org>, "Herve Ruellan" 
<ruellan@crf.canon.fr>, <xml-dist-app@w3.org>, "Yves Lafon" 
<ylafon@w3.org>, (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        RE: New AFTF draft.



Yup, representations (bags of bytes) travel. Resources "just are". This
is completely independent of HTTP.

Henrik 

>Well, my understanding is that HTTP GET+URI returns a 
>representation of the resource at that URI; resources don't travel.

Received on Wednesday, 11 September 2002 13:34:42 UTC