8.3. Alternative Storage TechniquesTo store larger cookies or more complex objects, previous applications have used a variety of hacks, including a LiveConnect interface between JavaScript and Java applets, or ActiveX controls. Another approach is to use hidden elements in forms to persist the data from form submission to submission. An approach gaining increasing popularity, especially with the advent of Ajax technologies, has been to use the Flash built-in persistent mechanism. 8.3.1. Communicating Outside the BoxLearning JavaScript never ends. Just when you think you've worked with all aspects of the language, something else comes along. It might be fun, it might not be fun, but there is more to this little lightweight language than first meets the eye. As I mentioned in Chapter 1, JavaScript was originally intended to be one half of a one-two punch put out by Netscape: functionality created on both the server and the client browser, with communication between the two through an integration plug-in known as LiveConnect. Through LiveConnect, developers working with the newfangled programming language Java could interface directly to JavaScript on the browser. Nowadays, most server-client interaction happens through Ajax, which is described in Chapter 13. But in those early times of technological exploration, LiveConnect was one sexy concept. Much of the Flash/JavaScript early integration was based on this LiveConnect interface, though Macromedia eventually created its own scripting language, ActionScript, for its side of the equation. You can still manipulate Flash functionality through JavaScript, and web-page objects and JS through Flash. There's even a Flash-to-JavaScript integration kit, though it looks rather cobwebby and untouched.
Through this open door between JavaScript and Flash, a new storage medium was discovered when those creating more sophisticated client applications needed something more in the way of persistent storage on the client. This new form of Flash-enabled cookie, or super cookie as it's sometimes called, can be up to 100 KB and can take any form of JS object, not just primitives. The storage is managed through a specific object: the Flash Shared Object. 8.3.2. The Flash SO and Dojo StorageShared Objects (SO) in Flash operate in a manner similar to HTTP cookies. They're stored and accessible based on a domain, and pages served from one domain cannot access shared objects created from another domain. This sandbox protection was incorporated as part of the design of Shared Objects from Flash Version 7 and up. Unlike the HTTP cookie, with its 4 KB limit, SO storage is unlimitedbut only silently up to the first 100 KB. What this means is that if a web page or web application from one domain tries to set a SO greater than 100 KB, a message box opens asking for permission to use this space. The client then has to provide explicit permission for the SO to be set. Of course, a drawback to using the Flash SO is having to work with Flash in addition to JavaScript. However, others have been down this path and have kindly provided open source implementations of this technology. One such is Brad Neuberg's Dojo.Storage (described, demonstrated, and linked in this weblog post: http://codinginparadise.org/weblog/2006/04/now-in-browser-near-you-offline-access.html). Dojo is an increasingly popular Ajax tookit, which I describe in Chapter 14. The Storage library is an interface to multiple storage techniques, including using XPCOM (for Firefox), and ActiveX (for IE), as well as Flash for cross-browser support. Over time, other approaches that enable client-side storage beyond the limits of cookies will be developed. The question then becomes: should we use them? 8.3.3. Could You, Should You?Could you, should you, though? Before getting into the mechanisms that allow you to load down the client, should you? And if you do, should you let the client know? If you are providing a functionality that your client wants, by all means, load down the client machine. However, you should give upfront notice that this is going to happen, rather than sneaking the data in through a back door. All the whizzy frontend functionality won't compensate for taking a significant amount of client space, leaving your client wondering what's going on. A good rule of thumb is never use so much client space that your clients will notice it, unless you give them a heads up first. Any other practice would be just plain rude. Beyond taking client space, there are privacy concerns. Browser cookies are very visible. After all, they are just small text files locally stored on the client. You can see these cookies through your browser, as shown in Figure 8-4. You might not recognize all of them, but at least you can see what's there, and (depending on your browser) individually remove each. Figure 8-4. Peering into the browser cookiesOther approaches may not give this option. As it is, several online ad companies have been exploring the use of Flash to track a person's movement through various sites. Additionally, wherever there's an opening, the bad folks will exploit it. Enough so that many people are turning off Flash, even as they contemplate turning JavaScript back on.
Figure 8-5. Editing JavaScript using the Eclipse IDE |