The reason I am doing this is simple. I want to encourage a discussion
on this and not silently let the idea die because it didn't come to
people's attention. Any outcome in favour or against is fine but I
want to avoid just silence. I have already posted this here, see my
note and apologies at the end of this post.
The idea solves a consequence of common browser behaviour. Browser
merge cookies of all open windows into a single cookie storage.
Session state of a web application is mostly held as a cookie. In most
use cases this is fine and expected behaviour for the user. The user
logs in once and if he opens an URL of the same website in a new
browser window, he is still logged in.
On the server side there is a session context which corresponds to the
session id stored in the cookie. The trade off of merging is that if a
web application stores data into the server session, another window of
the same application could overwrite this data. This problems leads to
a number of work around which solves the problem partly but introduce
other technical requirements like JavaScript application on client
side or forces to keep track of a kind of id (conversation scope). I
got quite some feedback how to work around this problem. I posted the
comments and explained the trade of of those ideas in more detail in
my blog at http://www.laliluna.de/blog/2009/05/19/browser_feature_request.html
This problem could be cleanly and easily solved with a window id, sent
by the browser as request header. This allows to leverage the normal
server session and to split it into areas identified by the window id.
A web application could now safely store data into the server session.
Window could no longer influence or overwrite data stored by another
browser window.
Imagine a web application to write longer articles like that one. You
store the new not yet saved article in the session. You navigate to
the dialog to edit a new paragraph, add a paragraph, add another one.
The submit of a new paragraph takes the article from the session
context and adds the paragraph. It is straight forward. Then you open
a new browser tab, have a look on the discussion list and suddenly
want to reply to another thread. You will either overwrite the other
article stored by the first browser window or be blocked if the web
application is friendly and tells you that you are already creating an
article. With a window id, you can separate articles per window id.
You don't have to take care, if the user opens a new window. You can
provide a consistent user interface without great effort. You can
easily distribute application state between client and server and you
are perfectly aware of which state belongs to which browser window. It
could be so clean.
In HTML 5 this problem is already addressed for the client side with a
sessionStorage. When defining HTML 5, contributors where clearly aware
of the problem. But web application with server side state are still
suffering. The more we use web browsers not to display content but to
run applications, the more it is annoying that we cannot hold session
state on the server in a safely and consistent manner.
I hope that I managed to make the advantage of my idea clear. If not
just let me know and I will try to provide a better explanation.
I created a ruby based sample application to demonstrate the advantage
of a window id.
http://www.laliluna.de/blog/2009/05/28/browser_feature_request_sample_application.html
Clean up notes:
I posted the idea already two weeks ago, so I basically bumped up a
thread.
http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/3ad19d509ad01f5e
Knowing that this is considered to be bad style, I hope that
chocolatifying a discussion thread is less offensive. Still, I
apologize for this.
Outside of Europe, I can only sent you money using Paypal to buy a bar
of chocolate.
I only have 10 bars of chocolate or Paypal equivalents to distribute.
Best Regards
Sebastian Hennebrueder