- From: Noah Mendelsohn <nrm@arcanedomain.com>
- Date: Wed, 09 Mar 2011 20:02:37 -0500
- To: "T.V Raman" <raman@google.com>
- CC: ashok.malhotra@oracle.com, www-tag@w3.org, jeni@jenitennison.com
On 3/9/2011 4:47 PM, T.V Raman wrote: > Itend to agree with Ashok here. The '?' is well understood as the > server-side param. I think that, in the long run, having identifiers be either "client-side" or "server side" is a mistake, though certainly that idiom is out there. To the extent practical, we want the same identifiers to work everywhere. An example of where this is breaking, is that Ajax-orginated identifiers with #, such as #!, tend not to work when sent to non-Javascript clients. Conversely, ? identifiers can be interpreted at both client and server; Google maps URIs work OK from mobile devices that lack Javascript, and are crawlable. > only lead us furthe rinto our original comfort zone of "state is > managed on the server" Not where I'm going at all. I want a syntax that can be interpreted transparently, server and client, with good Javascript control over when you do or don't want server interaction. ? seems like the more promising long term syntax; stated differently, I think it will be easier to start building user agents that allow Javascript to set a ? URI at the client without initiating server interaction, than it will be to get fragment ids into the HTTP Request-URI when you need them interpreted at the server. That being the case, if we want an identifier that works equally well at both ends, with good control over when server interaction occurs, ? is the more promising long term choice. Clearly that's not what implementor's are doing today, but I posit that's mainly because the user agents they have do insist on contacting the server when a ? URI is changed. Fix the user agents, and ? may start looking better. Certainly none of the normative specs indicate that ? is server-focused. Noah
Received on Thursday, 10 March 2011 01:03:11 UTC