- From: T.V Raman <raman@google.com>
- Date: Mon, 7 Jun 2010 12:05:35 -0700
- To: nrm@arcanedomain.com
- Cc: raman@google.com, www-tag@w3.org
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