Re: HashInURI

For the Google Maps example, the text says (in 2.2)
<<
The URI that Google Maps creates for the displayed map has a long 
server-side parameter but no fragment identifier. This is because the maps 
are images and must be fetched from the server. If the maps were drawn 
using vector graphics, some of the scrolling and zooming could have been 
done on the client.
>>

I don't agree with that rationale. It is in fact easy to compute the tiles 
addresses based on the screen size, zoom an location (as you can compute 
easily based on the projection in use the min lat/long and max lat/long).

In that case, I suspect an optimisation to avoid waiting for javascript 
onload() event and have the browser start fetching the right tiles
(computed server-side), as the tiles download will start before the entire 
page is fetched. So it is more a latency optimization than the fact that 
it is vector graphics or tiles, especially as you can have vector graphic 
tiles !

Also, the entire URL can be used as a parameter for the script, so the CNN 
example might work almost the same if the parameter was after a '?' or 
after a '#', the major difference is that in the case of a hash, 
subsequent calls with a different hash will use a cached version of the 
HTML page and be more efficient as there only one content to be downloaded 
when the script is executed. In the GMap case, as there are more linked 
content to be retrieved in parallel, it is more efficient to be 
cache-unfriendly but download faster.

Of course it also has implications on what is identified by the URI, but 
efficiency is also part of the design decision when it come to when to use 
'?' or '#'.


-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Friday, 3 December 2010 15:18:14 UTC