[whatwg] Some likeness of DOM Session scope

[Dimitri Glazkov]

At first, I envisioned a fairly simplistic (perhaps naiive would be a
better word) functionality:

An initially empty JS object, which survives from request to request
until the browser window is closed. This object is implicitly
instantiated once per session for each domain, and is the same across
all windows/tabs.

Being the associative array that it is, the object can be populated by
whatever data or functions that need to survive throughout the
session.

Obviously, you can see some serious potential security, memory usage,
and just plain compartmentalization issues here.

Then, after reading the thread, it seemed that maybe I am looking at
the problem from the wrong end:

Maybe it would a better idea to introduce functionality that
standardizes a usability-perfect simulation of a request within the
same page? I think that is what Brad is writing about.

In other words, instead of trying to come up with a vehicle that
allows you to pass data across independent requests, devise ways to:

* identify (create) state of an application inside of a  page
* communicate it to the browser's address bar and history navigation
* restore the state when the browser asks for it (via back/forward or bookmark).

With this in place, history can be manipulated at will and a
transparent user experience of browsing multiple pages can be created
within the same actual page.

I believe Microsoft has toyed with this concept in IE5 by introducing
#default#saveFavorite and #default#saveHistory behaviors.

Or maybe it's both: a serializable/deserializable persistence
mechanism across independents requests and the way to manipulate the
history.

What do you guys think?

:DG<

On 4/21/05, Brad Neuberg <bradneuberg at yahoo.com> wrote:
> Something along these lines that would be useful is
> control over what goes into the history (and what
> affects the back button) and what _doesn't_.  Alot of
> times I shoot off RPC type functions using
> XmlHttpRequest that I _dont_ want in the history,
> since they wouldnt be appropriate for the back button,
> and other times I want the back button to be affected.
> 
> Brad
> 
> --- Dimitri Glazkov <dimitri.glazkov at gmail.com> wrote:
> > IMHO, one of the biggest obstacles for growth in Web
> > applications
> > development is the fact that the entire application
> > lives in the scope
> > of one request.
> >
> > Once next request is made, the browser essentially
> > "forgets"
> > everything and the whole new cycle of loading,
> > initialization, and
> > binding begins.
> >
> > Yes, you can simulate the effect of retaining scope
> > across several
> > requests with XmlHttpRequest and even frames, but
> > it's the "simulate"
> > part that bothers me. "Simulate" means "hacking",
> > and "hacking"
> > inevitably means inconsistent and/or incomplete
> > implementations.
> >
> > It seems that a future Web Application platform
> > should have this type
> > of functionality readily available. What do you
> > think about the idea
> > of having some likeness of a scope that's inherently
> > wider than
> > request?
> >
> > Consider this example (improvising here):
> >
> > Request 1:
> >
> > function SyntaxHighlighter()
> > {
> > // code goes here to provide on-the-fly
> > beautification of code
> > }
> > document.session.highlighter = new
> > SyntaxHighlighter();
> >
> > Request 2+:
> >
> > if (document.session.highighter)
> > {
> > var codeSections =
> > document.getElementsBySelector("pre > code")
> > for(var i = 0; i < codeSections.length; i++)
> > {
> > SyntaxHighlighter.apply(codeSections[i]);
> > }
> > }
> >
> > Is this a totally asinine idea?
> >
> > :DG<
> >
>