- From: T.V Raman <raman@google.com>
- Date: Mon, 24 May 2010 14:52:37 -0700
- To: nrm@arcanedomain.com
- Cc: raman@google.com, www-tag@w3.org
Noah, You're missing a fairly vital aspect of URI interaction in AJAX applications --- and something I believe is spelt out in the write-up --- but clearly not well enough. I'll articulate it below, and you can tell me how better to articulate it so it's not missed. In your entire wakl-through of the algorithm, where the client mints a URI, and the server and client understand how that minting occured,it sort of slips by that not all aspects of the minted URI get sent to the server. Thus: Take application at example.com that serves beer. Beer served is parameterized by type of brew, size and shape of glass, amount of head when the beer was poured, etc -- all so you can share that experience with friends and ensure that they get exactly what you got. So far so good. In the world of Web 1.0 and exclusive server-side args, the server minted the url based on a form submission, and reprocessed the params when it later received one of those URLs. In the AJAX world of Web 2.0 applications and client-side state management the client mints a URL by pushing app state on to the URL: so: http://example.com/beer#{"color" : 1, "size" "16oz", "head" : 3, ...} Client shows this to you as the URL. You email it to your friend. Your firned hands it to his browser. The browser hands URL http://example.com/beer to the server. Server response contains a piece of code. This code runs on the client and receives the client-side args #{...} --- and voila, your application returns to the same state as was stored earlier. I think that last bit is important, and most of the web-apps client-side state draft focuses on how Web developers arrive at this authoring pattern in the various toolkits available. Noah Mendelsohn writes: > At our last F2F, Raman took ACTION-422, which was to incorporate into > the client side state draft finding a use case that I had described at > the F2F. Specifically, the intention was to encourge use of an idiom > implemented by Google Maps and some similar Ajax applications. Raman > subsequently did additional work on client side state [1], and reported > that he believes this work covers the use case described above. I took > ACTION-432 to check whether I agree. > > I think the writing at [1] is very useful, and I have no problem with > it. I agree that it provides at least part of the conceptual foundation > for promoting URIs that can be emailed and used outside of the > particular application instance in which they were "minted". That said, > I'd really like to see the map use case spelled out more directly. > > As a reminder, hightlights of the use case are: > > * The user uses a Web application to navigate through a rich set of > information; in the case of Google Maps, the user has the opportunity to > choose a location to be mapped, a zoom level, select a rendering, to > overlay information like driving directions or points of interest, etc.. > > * A URI is assigned for each possible state of the map. Both the client > and the server are aware of the the assignment algorithm, thus: > > * When the user manipulates the map at the browser, the application can > provide to the user a URI suitable for linking or emailing. > > * The server will, when presented with the URI, provide a response that > represents the "same" resource. > > * As with all repeated references to a URI on the Web, the > representation retrieved or presented may to a greater or lesser degree > be different than the one the first user saw. For example, a URI might > be assigned to a document showing traffic patterns at a particular day > and time, or it might be assigned to a document showing then-current > traffic. > > My hope is that someone who builds applications like the map, and who > reads our ultimate finding, will be motivated to assign URIs to (most) > every state that the user can encounter in the application, will ensure > that clients and servers agree on those mappings, and will ensure that > emailed links tend to work. I think Raman's note does a great job of > exploring some of the subtleties and challenges in making that happen, > but it stops short of saying in a positive sense: 1) do it and 2) here > is at least one approach that has often worked well. > > So, I hope we can do a bit more. Thank you. > > Noah > > [1] > http://xml-applications.blogspot.com/2010/04/on-web-applications-web-architecture.html > -- Best Regards, --raman Title: Research Scientist Email: raman@google.com WWW: http://emacspeak.sf.net/raman/ Google: tv+raman GTalk: raman@google.com PGP: http://emacspeak.sf.net/raman/raman-almaden.asc
Received on Monday, 24 May 2010 21:53:13 UTC