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

When I said "well-understood" I meant Web-developers who code in
HTML  and JS.

Noah Mendelsohn writes:
 > T.V Raman wrote:
 >  > Actually the maps use case is well  understood in the sense that
 >  > it's using server-side params to encode state.
 > 
 > My question is: well-understood by whom?
 > 
 > Clearly, the encoding of parameters in server-side parms is known at 
 > least as far back as HTML forms, and an in that sense, not new.  I find 
 > that many people don't understand how they are used in applications like 
 > Google Maps.  I think that explaining that the option is there, and that 
 > it has proven useful in high value production applications, is worth doing.
 > 
 >  > It's unclear to me
 >  > at this point whether a system that is entirely server-side
 >  > params is in some way "better" than one that uses a combination
 >  > of client-side and server-side params
 > 
 > That's a question I'd really like us to explore, but I'd rather not 
 > presume the answer. Also, I'm not comfortable with the term server-side 
 > only, since the whole point of the Google maps example is that the 
 > client and server agree on the assignments, and both of them conjure up 
 > new URIs as necessary.  Might we call it something like "no fragid 
 > model" or some such.
 > 
 > My intuition is that the fragid-free model might have the following 
 > advantages:
 > 
 > * Conceptual simplicity, relating in part to...
 > 
 > * A clearer story with respect to the applicable specifications:  in 
 > principle, fragment identifiers are, at least sometimes, defined by the 
 > media type specification for the document in question (which in the case 
 > of an Ajax app, begs the question: what document?)  We know that the 
 > fragid architecture causes trouble with, e.g. conneg.  Without fragids, 
 > we say:  "the URI assignment authority has decided that these parm 
 > values identify this point on the map".
 > 
 > * Is there some declarative story about the specification for such 
 > fragids, or is it just: run the Javascript, and it will work?
 > 
 > * Certainly it seems to me that there is a cleaner story on conneg with 
 > the no fragids approach:  you want a JPEG for that map, no problem.
 > 
 > I'm not in all cases against the fragid stuff if it solves a problem. 
 > Maybe you're right that avoiding fragids has no significant advantages, 
 > but I'm not yet convinced.
 > 
 > So, I think what we should probably do is prepare a much more careful 
 > analysis of the pros and cons.  If, as I suspect, there are some 
 > advantages to, when possible, avoiding the munging of fragids, then what 
 >   I'd do is:
 > 
 > * Tell the Google Maps story as a base case.
 > 
 > * Explain the pros, if any, and cons of using fragid munging to get 
 > richer function at the client
 > 
 > If, as you suspect, there isn't much pro or con either way, or the 
 > fragids are a clear win, then it might be worth setting down why that's 
 > the case.
 > 
 > Noah
 > 
 > T.V Raman wrote:
 > > Actually the maps use case is well  understood in the sense that
 > > it's using server-side params to encode state. It's unclear to me
 > > at this point whether a system that is entirely server-side
 > > params is in some way "better" than one that uses a combination
 > > of client-side and server-side params -- note:5 years ago I'd
 > > have answered differently ie, said "server-side params" are a
 > > better pattern.
 > > 

-- 
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, 7 June 2010 19:06:10 UTC