Re: Context dependent

On Wed, Aug 28, 2002 at 02:03:58PM +0200, Stefan Eissing wrote:
> 301 is a bad choice since this indicates that "... the requested
> resource has been assigned a new permanent uri..." (RFC 2616). But
> the "neaerest gas station" resource is still at 
> http://example.org/nearest/gas/.
> It just "points" to a another resource which is the nearest one
> according to "context" information. So 302 would be better, but
> not ideal either.

My bad.  After all these years, I still get 301 and 302 confused. 8-(

> The context sensitivity should be better named request sensivity,
> since, talking about http, this should determine the response.
> 
> The best way to implement "nearest gas station" would be to let
> http://example.org/nearest/gas/ return a (request-sensitive)
> representation of the specific "gas station" resource and set
> the Content-Location header to the URI of that particular gas
> station (and set the Vary header accordingly).

I'd say the best way to implement it would be with a network of
intermediaries, where each intermediary handled a particular geographic
area, similar to the Akamai network.

> So, in my - maybe limited - understanding 
> "http://example.org/nearest/gas/"
> is a resource like any other. It returns request-sensitive 
> representations
> like any other http resource.
> 
> Or, to put it simply: I don't get it (context sensivity of absolute
> uris).

The difference is whether the contextual information is part of the
message - such as a header specifying your location - or part of the
context in which the message is transferred - such as a proxy that you
used to send it.  The latter is what I what I meant by "context
sensitive/dependent", but I agree that the former is probably covered by
that wording too.  I'm not sure how best to clarify this right now, but
I'll think about it.

Thanks.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com

Received on Wednesday, 28 August 2002 08:47:12 UTC