[whatwg] Some likeness of DOM Session scope

[Sjoerd Visscher]

Ian Hickson wrote:
> I used this idea for the window.history.pushState() idea:
> 
>    http://whatwg.org/specs/web-apps/current-work/#the-session
> 
> Let me know if you have any comments.
> 
> It doesn't cover the bookmark case, only the back-forward case, so I don't 
> think this removes the need for a cross-page-load and persistent local 
> store. You still need something for, e.g. offline applications, and for 
> applications whose "sessions" are likely to outlive the actual browsing 
> session. For most cases this information might be better dealt with using 
> a session cookie and server-stored data, but I can definitely see some 
> cases (especially games and "productivity" applications like 
> word-processor-like things) that would require local data storage rather 
> than wanting to depend on the network.

I think it is great!

Now, what I'd really like to see a solution to the "bookmarking 
problem". Well, it's really not a bookmarking problem, because you can 
simply do

   location = "#...some representation of the state of the page..."

And you can bookmark that. The bigger problem is Google. Google afaik 
completely ignores fragment identifiers. So if f.e. the bookmark 
location was "http://www.example.com/#salesdep", and everybody is 
linking to that location, there are 2 problems with Google:

1. Google doesn't support javascript. But it is impossible for the 
server to send a static page of the sales department, because fragment 
identifiers are not sent to the server with http requests.
2. Because of the links, Google will add the page to its database, but 
it will remove the fragment identifier. So even clients with javascript 
support will see the homepage instead of the sales department page, when 
they found the page through Google.

So what we need is a way to change the path or the query part of the 
location, without getting a page reload. I think it works best (security 
etc) to just allow to change the query part. It would probably make the 
most sense to make this the second argument to pushState.

In our example we could do

   history.pushState(data, "salesdep")

and get http://www.example.com/?salesdep in the address bar.

When Google, or any other non-AJAX client, follows that URL you can let 
the server generate a static sales department page. AJAX clients get the 
basic site framework, and the client will read the query string and go 
to the sales department part.

-- 
Sjoerd Visscher
http://w3future.com/weblog/