[whatwg] Some likeness of DOM Session scope --> Steal Flash's SharedObject Syntax

[Brad Neuberg]

Flash MX has a scriptable object named SharedObject that can contain far 
more application state than a normal cookie can, but for Flash 
movies.  Perhaps this is a good concept to steal from Flash?  They've 
thought through the API pretty well.  One thing that is unique about these 
is that they can store binary, so that you can actually serialize the state 
of your Flash ActionScript (which is just JavaScript now) right into your 
cookie, making programming in Flash very productive.  You can also store 
images, sounds, video etc., leading to very fast startup time for apps that 
use these.

Some more info on SharedObjects at 
http://www.macromedia.com/support/flash/action_scripts/local_shared_object/:

"Local shared objects provide a way to maintain locally persistent data 
(similar to "cookies" stored by web browsers). For example, you can create 
a shared object, such as a calculator with memory, in the player. Because 
the shared object is locally persistent, Macromedia Flash MX saves its data 
attributes on the user's machine when the movie ends. The next time the 
movie runs, the calculator contains the values it had when the movie ended. 
Alternatively, you can delete the shared object before the movie ends, in 
which case the calculator opens without any prior values the next time the 
movie runs. "

About size considerations:

"Local shared objects are always persistent on the client, up to available 
memory and disk space.

By default, Macromedia Flash MXcan save locally persistent remote shared 
objects up to 100 K in size. When you try to save a larger object, the 
Macromedia Flash Player 6displays the Local Storage dialog box, which lets 
the user allow or deny local storage for the domain that is requesting 
access. Make sure your Stage size is at least 215 x 138 pixels; this is the 
minimum size Macromedia Flash MX requires to display the dialog box."

In terms of security, we should be careful that these can't be used as a 
vector to attack the local system, either through a buffer overflow attack 
or a way to get a binary image onto a machine that can then be manipulated.

One note: when a user clears their cookies we should also clear out these 
SharedObjects, probably presenting them to the user as super-charged 
cookies, to prevent a similar security bug that affected Flash.  There is a 
sneaky adware attack called PIE that stores cookies into a Flash's 
SharedObjects, pulling them back out if a user clears their cookies since 
Flash didn't hook clearing the SharedObjects into clearing the cookies in 
the browser.

At 07:58 AM 4/22/2005, Dimitri Glazkov wrote:
>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<
> > >
> >

Brad Neuberg, bkn3 at columbia.edu
Senior Software Engineer, Rojo Networks
Weblog: http://www.codinginparadise.org

=====================================================================

Check out Rojo, an RSS and Atom news aggregator that I work on.  Visit 
http://rojo.com for more info. Feel free to ask me for an invite!

Rojo is Hiring!  If you're interested in RSS, Weblogs, Social Networking, 
Java, Open Source, etc... then come work with us at Rojo.  If you recommend 
someone and we hire them you'll get a free iPod!  See 
http://www.rojonetworks.com/JobsAtRojo.html.