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

FWIW, many I know, and myself included, have ended up using fragment 
parameters as a way of allowing history for 'AJAX' applications, without 
the URI change there's no way to give users the back/forwards 
functionality in the browser, hence adopting the #fragments and saving 
the state in them so we can give users history functionality without 
reloading the full page (and thus negating the benefits of 'ajax').

Unsure what that adds or take's away, but hope it was worth mentioning.

Best,

Nathan

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

Received on Monday, 7 June 2010 20:39:21 UTC