ACTION-432 and ACTION-422: Maps use case in client side state finding

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