- From: John Kemp <john@jkemp.net>
- Date: Thu, 10 Mar 2011 10:06:22 -0500
- To: Jeni Tennison <jeni@jenitennison.com>
- Cc: www-tag@w3.org
Jeni, On Mar 10, 2011, at 9:30 AM, Jeni Tennison wrote: > 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. Indeed! URIs can often be passed around usefully, and stateful Javascript... not so much. > >>> 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. Can I (or another person) cut and paste that URI from the browser address bar and send it to you, and expect something meaningful to happen in your browser? And if the address in the address bar isn't the one I want to pass around (say I'm in Google Maps and the address bar says maps.google.com, but I've actually navigated to my current location and want to send a link to you which brings up this location in Google Maps - that URL looks like this: http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=panera,+pittsfield&aq=&sll=37.0625,-95.677068&sspn=47.215051,105.556641&ie=UTF8&ll=42.468425,-73.204479&spn=0.04166,0.103083&z=14&iwloc=A) what is the "best practice" for allowing me access to this URL? Google provides a link called 'link' which I can use to access this URL. > > I must be missing something. It may, of course, be me that is missing something ;) > Can we try to find an example where something more is needed? Personally, I guess the only question I have is whether URIs created in the process of updating browser state may be passed around usefully. If not, why not? And if so, are there any particular practices that made them this way? Regards, - John > > Cheers, > > Jeni > -- > Jeni Tennison > http://www.jenitennison.com > >
Received on Thursday, 10 March 2011 15:06:58 UTC