Re: network endpoints

Real, you said, you wanted to connect to something real. Hmmm.
I don't find the abstraction of the 'network endpoint' associated with  
e resource to be any more real.  I find creating new abstract concepts  
is only useful when it gives us something which we didn't have before  
hang a lot of common meaning off.  In this case, we have the  
abstraction of the resource, and we do have a server which has a role  
in the HTTP protocol, and is controlled by the domain name owner, and  
so on.  I don't se a use for some concept like "that in the server  
which corresponds to this resource". If the resource is served up by a  
php script common to millions of resources on the server, I can't see  
the 'reality' of the network endpoint.

The server, though, is something closer to real.  It is actually the  
thing which responds with a 200. It has a domain name, port, etc.  It  
actually is in that sense a network endpoint - a transport level  
endpoint.  (The server host is a network level endpoint).

If you like, a resource is a web thing, and a server is a transport  
thing.   I don't see a need for the endpoint you describe.

Tim


On 2008-04 -25, at 15:45, Jonathan Rees wrote:

>
>
> On Apr 25, 2008, at 10:33 AM, noah_mendelsohn@us.ibm.com wrote:
>
>> Stuart Williams wrote:
>>
>>>> [Jonathan Rees wrote:]
>>>
>>>> I'll make the change in a day or two or three if I hear no outcry.
>>>
>>> I guess consider this a little cry out :-)
>>
>> Sorry for not chiming in earlier, as I've been traveling.  Anyway,  
>> I'm
>> afraid I agree with pretty much everything Stuart is saying here.   
>> I think
>> the system is best thought of in layers.  When you refer to  
>> endpoint, I
>> presume you mean something that has some sort of persistent existence
>> across HTTP interactions.
>
> Not really. I just mean "the web" in the role of dealing with some  
> particular URI.
>
> I just want a way to say what is obvious but not said yet, that  
> "information resources" relate in some way to the web. Remember that  
> IRs, as I've heard repeatedly confirmed, are abstract things that  
> may be put on the web, but are not inherently part of it. So we have  
> to perform an explicit step to say that the behavior of the web can  
> be consistent with a URI "identifying" to the web the abstract  
> document that it denotes. This is part of the HTTP spec and  
> therefore something that has to be articulated about HTTP semantics.  
> I accept Stuart's suggestion that we talk about an abstraction "the  
> web" as the apparatus for handling requests without diving deeply  
> into its nature. I was going to make a node for the class of things  
> of the form "the web at a URI" in the diagram, and an arc in the  
> diagram connecting that node to Abstract Document / IR signifying  
> that if a URI U denotes an IR X, then the web needs to deliver  
> values, at U, that represent X's state at the time the request was  
> processed.
>
> "Endpoint" seemed like a nice shorthand to describe the web  
> specialized to a particular URI. But since "endpoint" is making both  
> of you squirm, I will try to think of something else. Maybe "URI- 
> specific web behavior".
>
> I'll make a new version of the diagram, in any case.
>
> If I'm still being unclear then it may be what I'm trying to do is  
> state something so numbingly obvious that it is invisible and  
> therefore, when stated, sounds controversial. But that what  
> semantics is about.
>

Received on Wednesday, 30 April 2008 17:55:50 UTC