Version 1.4 has been commented here.
- fixed iframe problem, now standard behavior
- a singleton for each context (window, frame)
- same storage area for each context (main top window)
- no more disabled flag, typeof sessionStorage !== "undefined" to use it
- waiting to understand how exactly events are fired but the code is ready to manage them
Yesterday night I twitted about it, this evening I've finally found time to write down the Home Page in Google Code.
You will find everything in the home page, or in the source code, while here there is a first basic demo to try out.
I would like to know your opinion about it, so do not hesitate to write some comment!
P.S. please note that the minified version, once gzipped, is less than 1.5Kb ... enjoy ;)
That's a pretty cool implementation Andrea! Using RC4 a crypto solution for storing content is simply brilliant. Thanks for sharing!
ReplyDeleteI like it a lot... a few questions/comments, though:
ReplyDelete1. I don't see any storage events firing -- will you be adding that?
2. If I navigate away from a.com to b.com and b.com also uses this API the session from a.com will be overwritten by b.com session, but once you go back to a.com, a.com will be operating on the b.com session string. Maybe a session-site association key in addition to the check for the cookie being present?
3. Unless I'm missing something / not thinking straight this will not play nice with iframes
Thanks again and hopefully my comments are helpful.
1 - events will be somehow supported, right now events are not a priority.
ReplyDelete2 - my implementation is based on RAM and window name - no physical storage is used. This mean that if I would like to store everything from every domain, RAM usage could go up to hundred of megabytes and every search will become slower domain after domain. This is why window.name is clear for each new domain but you are right, when you come back you will have b.com string. In any case, to know if a session is active we should simply check if(sessionStorage.getItem("populated") === "OK"){ ... all our stuff ... }
which is natural usage.
A filter like that should fail due to different RC4 key but probably I need an entry in the wiki page in order to explain these kind of problems.
3 - as we can use opener.sessionStorage I guess we can use parent.sessionStorage as well no? Obviously the sessionStorage script has to be included in the top context but if our page is included as an iframe sessionStorage should work without problems. I'll do some test, thanks.
I was rather thinking aboud RC4.encode($key, document.domain) as first entry in the window.name so that if window.name.indexOf(RC4.encode($key, document.domain)) < 0 I clean it.
ReplyDeleteI know it will make this sessionStorage usable for one domain a time, but hey ... it is an "emergency" script, IE8, Firefox, Safari, and Chrome already implement this object!
I think it should be fine for it only to work on one domain at a time in the same window. If there is enough adoption that this becomes an issue, it would be easy enough to support n domains in a stack.
ReplyDeleteAbout window.name;
ReplyDeleteOld versions of IE6 (with out service packs installed) will crash if you store data larger than 250~ kb.
So you might wanna be careful with that.
so maybe they'll realize it is time to update ... OK still IE6 until 2014, now we have to take care even about those IE6 not updated? This is anti progression and I am not sure I'll take care that much.
ReplyDeleteIn any case, thanks for the info first, and tell me if now makes sense to support multiple domain, 'cause that's what I am trying to code right now ... Regards
You could just sniff for service pack version
ReplyDelete(navigator.appMinorVersion) check for content length, if sp3 and lenght < 250k~ just don't store it..
You can always use flash or gears as backup to..
3rd parts software is probably the best way.
ReplyDeleteI do not want to use 3rd parts software.
I think 250Kb as limit is reasonable for common tasks but right now I am more focused in testing, events assignment, and the multiple domain support is not a priority.
The real case scenario for sessionStorage, which is not localStorage, is for a session. As long as the user is in the same domain or simply website, we have a way to store info. If we would like to save everything we already have openDatabase, localStorage, Flash, or whatever other plugin, which is good, but sometimes all we need is to keep a session info that will not go away if the user press F5 or change the page.
Probably that suggested check will be as filter, if there is such IE6 crap version, the sessionStorage will not exists at all.
I do not want to slowdown 99% of cases because of some silly user.
I am also thinking I can simply get rid of the disabled not standard property, so that typeof sessionStorage === "undefined" will make more sense.
Such a great article which ixed iframe problem, now standard behavior
ReplyDeletea singleton for each context
same storage area for each context
no more disabled flag, typeof session Storage undefined to use it
waiting to understand how exactly events are fired but the code is ready to manage them.The night It twitted about it, this evening it finally found time to write down the Home Page in Google Code. Thanks for sharing this article.