Re: Identification of documents in Web applications

Noah, I hate to say this -- but at this point, JavaScript is part
of the Web platform, and trying to insist that URL  references
make sense outside a javascript evaluation context does not make
sense on today's Web.  Perhaps the bug was that we didn't (early
enough) invent a URL mechanism that made it obvious as to what
evaluation environment  the URL required --- but that's water
under the bridge. URL de-referencing has always relied on bits
from the evaluation environment --- though admittedly, expecting
a JS  interpreter is a big leap from the past. 

Noah Mendelsohn writes:
 > 
 > 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 17:37:55 UTC