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

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

Received on Tuesday, 18 May 2010 21:48:20 UTC