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

Raman,

Thank you for this detailed followup.  The essential point you make is:

 > it sort of slips by that not all aspects of the
 > minted URI  get sent to the server.

I understand that there are many interesting Ajax applications that do 
this.  I agree with you that it's a story worth telling, and I did see 
it in the writeup.

That said, the example I gave at the March F2F and the one I encouraged 
you to write up as good practice is based on Google maps, which I hope 
we would agree is (1) an interesting Ajax application and (2) one that 
does indeed represent an interesting model for the handling of URIs.

In my experience with Google Maps, it does not do the fragment id trick 
that you describe.  For example, here is the URI offered by the client 
for "Google, Mountain View, CA".

http://local.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=google,+mountain+view,+ca&sll=37.0625,-95.677068&sspn=48.77566,114.169922&ie=UTF8&hq=Google&hnear=Google,+Amphitheatre+Parkway,+Mountain+View,+CA+94043&t=h&z=15&iwloc=A

There is no fragement ID, and I think it matches very well the story I 
told (or I'm still missing something).

So, what I'd like to encourage you to do is:

1) Tell the Google maps story as the base case.  I think it represents a 
simple ideal that many applications can aspire to.

2) With that as a base, elaborate the story to indicate what happens 
when the client uses fragment-ids or other means to track client-only 
state.  Tell a story about good practice in this case, and if necessary, 
explain how it relates to case 1.

Does that make sense?  Many thanks.

Noah

T.V Raman wrote:
> 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
>  > 
>

Received on Tuesday, 1 June 2010 02:23:38 UTC