Window ID Concept - practical use cases
Sebastian
in my effort to popularize the idea of a window id sent by the browser
as request header, I added now some practical use cases to illustrate
that there are things that you cannot do easily today when building
web applications.
Just for those hearing the first time of the idea:
If the browser sent an id unique per browser window, we could store
data (open menus, displayed widgets etc) per browser window and build
more stable stateful multi window web applications. HTML 5 solves the
problem on the client side of JavaScript applictions (sessionStorage)
but it is not yet solved for client server applications.
You can find the article in my blog.
http://www.laliluna.de/blog/categories/ideas/
I am looking forward to your feedback.
Best Regards
Sebastian Hennebrueder
http://www.laliluna.de
PS: I will cross post this to the webkit dev list as well.
Benjamin Smedberg
> Just for those hearing the first time of the idea:
> If the browser sent an id unique per browser window, we could store
> data (open menus, displayed widgets etc) per browser window and build
> more stable stateful multi window web applications. HTML 5 solves the
> problem on the client side of JavaScript applictions (sessionStorage)
> but it is not yet solved for client server applications.
As far as web architecture goes, having the server keep track of per-window
state sounds like a bad idea anyway, if there's any back-forward navigation
going on. I believe the answer to your request is WONTFIX.
--BDS
Sebastian
I would appreciate to be convinced that the idea is not useful. Could
you detail your argument?
In my opinion, a window id would be helpful especially in the case of
navigation.
Imagine a conversation with multiple steps, let's say 5 steps
(shopping cart checkout, complex editing of a product, ...) in an
application which can be opened with multiple windows.
To create such a dialog, it would be easiest to store data in the
session. It the user makes use of browser back and jumps to a page of
my application outside of this conversation, I could build a number of
use cases with the help of a window id.
a)
Ask the user, "Do you want to exit the conversation?" Clean up the
session, if he answers with 'yes' else send him back to the
conversation.
I couldn't do if I don't know which window is navigating.
b)
Leave the conversation as 'workspace'. I could show a number of
background workspaces. The user can select to a workspace and continue
editing.
c)
Just clean up the session. I know that Window foo switched to
something else and don't need the memory in the session anymore.
Another use case are rich JavaScript clients (GWT, Echo, Dojo and
alike). The common implementation strategy is to provide a stateless
server side service layer. If we could identify a window, we could
more easily make the server side more stateful as well and keep a part
of the data there. This is useful to cache data on the server outside
of the database. If you do this on the client then you can easily get
stale data on the client. A notification system or clustering can be
easily build on the server.
The option to split the session into a kind of slice per window,
allows you to build multi-page application in a much more stable way
without the need to educate the user to follow defined usage patterns
"Don't use browser back" or the developer "Don't use the session". It
helps to bridge the gap between the stateless nature of the web and
the stateful concepts of web application.
If you like, I could ask other developers to join this discussion. I
have discussed this with various people either directly or on the
Devoxx conference in Antwerpen and got quite some positive feedback.
I am looking forward to details on your argument.
Best Regards
Sebastian Hennebrueder