[EdSharkey]

Hey Marcus, I'm a user! Thanks for doing the heavy IE lifting in store.js.

Anyhow, I had a requirement to store raw strings to the local storage or userdata rather than go through your calls to JSON.parse/stringify. I forked and am using my fork rather than your maintained version, which is sad. Since you've got the hood popped for maintenance, would you mind adding raw string support to store.js in version 2? Thanks in advance. Here's my fork repo for reference, please see the getRawString and setRawString API's I added:

https://github.com/woldie/store.js

[greggman]

Genuinely curious but why is this important? Assuming the current API only takes an object can't you just provide 2 functions

    function putString(id, s) {
       storePutAPI(id, {s:s});
    }
    function getString(id) {
       var o = storeGetAPI(id);
       return o ? o.s : undefined;
     }

Note I have never used the API nor looked at the docs but assuming you can store objects why the need for special functions?

On top of which AFAIK JSON.stringify and JSON.parse work with plain strings so I'd be curious what prevents using plain strings in store.js without any changes

Sorry this isn't a put down , just trying to understand

[EdSharkey]

Not at all at all, I understand your confusion. Mine is definitely a niche case, perhaps straying a bit into the eclectic.

I have put together a virtual file system for a programming environment for kids that is built atop the local storage/userdata API's.

I support legacy IE back to IE6 as well as modern browsers, and I wanted to maximize my very limited allowed storage space on legacy IE.

Also, I needed to have some certainty around how much free space is remaining in the file system. My design was to organize the underlying storage into 4K blocks that were pre-allocated when the system first starts; whatever the host system could give me in terms of space I would take.

JSON is nice for the general case, but the way it escapes some characters makes computing the free space I have remaining unpredictable as new files get written.

Of course, I can do my own encoding of bytes into unicode char codes and write those as raw strings using store.js. JavaScript strings are saved as 16-bit unsigned arrays if you unfocus your eyes and stare at the screen for awhile, and I use as many bits as I am able in my scheme.

So, I rigged up a byte-to-string encoder/decoder that was universally accepted on IE and modern browsers, and calling through to my getRawString/setRawString API, I just about doubled my storage over the default JSON.stringify/parse!

Suprisingly, performance isn't bad with my encoded strings either. That said, my compy has a retro flair, and I don't think my users will mind much that they have to wait a second or two to load their games from disk. Perhaps even adds a bit of authenticity. :)

[marcuswestin]

Bonus points for best use case on the page :)))

Eclectic as it is, I think we should totally consider making it a plugin/storage! If you open an issue with links to the relevant material I'd really appreciate that. Thanks!

[marcuswestin]

Hi! Allowing users to add the plugin behavior they want is the whole idea, so let's do it :)

Could you please open an issue? If you include a short snippet with the rationale for what and why you need it that would help guide the discussion.

Thanks!

[EdSharkey]

Will do soon. Thank you Marcus!