- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Thu, 10 Mar 2011 14:30:50 +0000
- To: www-tag@w3.org
John, On 10 Mar 2011, at 13:56, John Kemp wrote: > On Mar 10, 2011, at 3:59 AM, Jeni Tennison wrote: >> On 10 Mar 2011, at 01:02, Noah Mendelsohn wrote: >>> Not where I'm going at all. I want a syntax that can be interpreted transparently, server and client, with good Javascript control over when you do or don't want server interaction. >> >> Isn't that what the HTML5 history API provides? > > How do you pass around that hunk of Javascript which identifies a particular state? Do you want to? Sorry, I'm confused. URIs identify states, not hunks of Javascript. >> What doesn't it do that you think we need? > > I hear some people want to pass client state around, and treat in general a resource/representation/document as a partial computation or "continuation". I don't think you can do that with HTML5 history alone. And currently, URIs aren't generally treated in such a way as to allow this. There isn't a generally-accepted way of writing a URI that says "the state of a computation at X", although people are makign attempts to use them roughly-speaking in this way. > > Do we want URIs to be used this way? If so, how should they be formed? My opinion: yes, we want URIs to be used to identify states, and they should be formed in the ways that they have always been formed :) It should up to the application designer to determine whether they want to name a particular state with a URI or not, and if so how that URI should be structured. Then all that's needed is a way to control whether a change to a new URI necessitates another request on the server or not, which is what the HTML5 history API gives. The Javascript that you use to update the page that the user sees can at the same time update the browser's address bar (and history) to provide a URI for the new state that the Javascript has taken them to, without the browser actually making a request to that URI from the server. So the Javascript is able to control when requests are made to the server, which is what Noah is talking about. I must be missing something. Can we try to find an example where something more is needed? Cheers, Jeni -- Jeni Tennison http://www.jenitennison.com
Received on Thursday, 10 March 2011 14:31:21 UTC