- From: Eric J. Bowman <eric@bisonsystems.net>
- Date: Thu, 10 Feb 2011 22:12:13 -0700
- To: nathan@webr3.org
- Cc: Yves Lafon <ylafon@w3.org>, Karl Dubost <karld@opera.com>, Ashok Malhotra <ashok.malhotra@oracle.com>, "www-tag@w3.org List" <www-tag@w3.org>
Nathan wrote: > > In reality everything is a different resource? well without getting > in to the semantics of this, because that statement is provably > false, I'll take it at face value to mean that everything which the > application provides a view of (or things which comprise a composite > view), in which case I think you'll find every "resource" is defined > by it's own unique URI, unless of course it's only available as part > of a collection. > Here are two different resources: http://twitter.com/#!/webr3 http://twitter.com/#!/ericbow We know they're different resources because URIs are opaque, and these strings aren't character-for-character identical. This is reality -- each user's feed is a separate resource, is it not? OTOH, since # has special meaning, any HTTP client will treat those as being the same resource, i.e. dereferencing either one will dereference http://twitter.com/ . This makes http://twitter.com/ the *one* resource being dereferenced for *everything*. > > > > > In this case, the semantics of the mapping of http://twitter.com/ > > varies based on the nature of the fragment, which can only be > > described as architecturally broken. > > > > it maps to an application, are you telling me now that an application > must not do anything? > I'm telling you that architecturally, that's backwards -- what we have here, instead of being Code-on-Demand, is Content-on-Demand. The former sends the content, along with instructions on how it is to be rendered. The latter sends the rendering instructions, along with some instructions on how to find the content. These are not the same style. These two URIs can also map to the same application, without any naming collision: http://twitter.com/webr3 http://twitter.com/ericbow HTTP clients don't see those as the same resource, because there's no fragment. The semantics of the mapping remain static, and are not a function of fragment contents. They can even be handled by different server processes, unlike with #! where they wind up being handled by the same server process. But, since those last two "proper" URIs are what get fetched anyway, what's the point of imposing a round-trip to get there? (That's a rhetorical question -- obviously, such chicanery isn't needed when proper architecture is followed from the get-go). -Eric
Received on Friday, 11 February 2011 05:48:12 UTC