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

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 Sunday, 6 June 2010 20:12:42 UTC