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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED] 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.
