Re: Identification of documents in Web applications

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