- Linear Storage Protocol finally consistent as a stand alone general purpose storage (string, file, request)
- RC4 Stream Cipher key generation without breaking characters (\x00 not in the random range)
- Cross Domain Support, if both site a.com and site b.com support my implementation, they will not delete or modify each other domain information
- optimized boot strap for frames and iframes, the storage parsing and reassignment is performed once and not every time which means zero delay when an iframe is injected or more frames uses the same implementation
Finally, few bug fixes and this version is both W3C Draft compatible and cross browser.
Known Supported Browsers
- Chrome 1 and 2, version 3 or 4 should have native support for Web Storage
- Internet Explorer 5, 6, and 7, 8 has native support for Web Storage
- Opera 7, 8, 9, and 10 beta, hopefully 10 final will have native support
- Safari 3, version 4 has native support for Web Storage
- Firefox whatever version, since it supports Web Storage since version 1.5
- Google Android and iPhone, but latest WebKit releases should support Web Storage
This is a mixed list of almost all A-Grade browsers but about Android and iPhone, the total amount of available RAM could be 2 Mb.
It is not suggested to store in any case massive amount of information but so far I have putted every kind of library avoiding server requests for each tab session and without problems.
The sessionStorage aim is, in any case, to remember an arbitrary amount of data for each session and for each tab, surpassing cookies limits without number of keys or amount of data limits.
This project will be part of vice-versa library in order to make vice-versa the cross browser "lingua franca" W3 framework able to bring standards where these are not present yet.
1.4 Special Guests
I would like to say a big thanks to Jonathan Cook (J5 in WebReflection comments) for his suggestions, patience, and ideas exchange ;)
Andrea,
ReplyDeleteNice work as usual.
Just wanted to drop a related note about a technique I used back in the days of IE 5 to provide session storage. Not sure if it still works, but I was able to share data across separate pages and domains by piggybacking data on the browser's window.history object.
Basically in IE you could add a property to the history object and store a serialized version of any object data in it. On a separate page (different domain) retrieve that data from the window.history object, deserialize, update, serialize and store it back on the history object. Serializing meaning converting to a string representation.
I have the sample code somewhere on my older system, and sites. If you're interested I can try to dig it up and share.
I had planned to write some code to inspect/detect which browser objects can be piggybacked across pages and domains, but other porjects took priority :-)
Like I said. Nice work. Always a pleasure to read what you're up to.
I found my old session code. History piggybacking works across domains with IE 5.5 & 6 but not IE 4, 5 & 7. I haven't looked into exactly why but perhaps 5.5 & 6 were exceptions.
ReplyDeleteWhy not use JSON instead of writing your own "string protocol?"
ReplyDeletebecause I do not want to serialize and deserialize plus encrypt and decrypt a possible massive amount of data for each stored key?
ReplyDeleteWould using a native JSON implementation be faster than a proprietary string algorithm, even if you had to encode/decode for every key?
ReplyDeleteevery browser with no sessionStorage support has not native JSON implementation.
ReplyDeleteDid you have any sort of problem with performances or compatibility?
Is there a reason to suggest something not that convenient for old browsers?
There is more than a reason I implemented LSS.
Regards
I must add that Android is probably the only exception but JSON will simply mean double usage of RAM and slower performances for each saved key.
ReplyDeleteAndrea,
ReplyDeleteNice work. I have a question on the size limit.
I wonder if there is any check to see if we have more session storage to use? It seems like an assumption that we'll never need to store more than 5mb of session info in there, but what would be the behavior if you hit that limit?
This is more a theoretical question as I'm not using your lib. But just to clarify; Do you retain objects in sessionStorage on reload/refresh? E.i. if I reload the page, with out closing it first.
ReplyDeleteof course, within the same window, yes.
ReplyDeleteIt would not be a sessionStorage polyfill otherwise :)
Unfortunately this seems to fail on safari in private browsing mode. The cause is best described here:
ReplyDeletehttp://stackoverflow.com/questions/14555347/html5-localstorage-error-with-safari-quota-exceeded-err-dom-exception-22-an
Are you still using this code and would it be worth fixing?
iOS7 has a broken localStorage while iOS any should have a working sessionStorage. If that is not the case it's about being Safari Mobile bugged in private mode.
ReplyDeleteHowever, this might be a common issue and if the detection is that simple it might be worth trying to fix this abandoned, jurassic, not used anymore code.
Stay tuned
please verify if this works for you
ReplyDelete