Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create way to store ArrayBuffer without converting to JSON #40

Closed
jviereck opened this issue Feb 9, 2014 · 5 comments
Closed

Create way to store ArrayBuffer without converting to JSON #40

jviereck opened this issue Feb 9, 2014 · 5 comments

Comments

@jviereck
Copy link
Contributor

jviereck commented Feb 9, 2014

In my usecase, I want to store ArrayBuffers using localForage. At the moment localForage converts the input to a string using JSON.stringify when using the WebSQL and localStorage backends. For binary data, I think it is more reasonable to convert the input array to base64 string and then store it in the WebSQL/localStorage data base.

How does the idea to store the data in base64 encoding sound to you? Would you accept a PR that implements this feature?

PS: Issues that might be related to this: #28

@fwenzel
Copy link
Contributor

fwenzel commented Feb 9, 2014

This might actually be the same as #28 indeed. I do agree base64 makes more sense than stringify for these. Now, base64 inflates size by 1/3, so potentially a different encoding is better, but either way, it'd be a good start at storing blobs.

@jviereck
Copy link
Contributor Author

jviereck commented Feb 9, 2014

Now, base64 inflates size by 1/3, so potentially a different encoding is better, but either way, it'd be a good start at storing blobs

Good point. Is there a technical problem that prevents us from concatinating the String.fromCharCode(x) result of every single byte:

// Just JS-Pseudocode
stringToStore = arrayBuffer.map(function(c) { return String.fromCharCode(c); }).join('');

@tofumatt
Copy link
Member

tofumatt commented Feb 9, 2014

Off the top of my head, I’d think speed. But that’s just a guess.

@tofumatt
Copy link
Member

I'm okay with base64 encodes for localStorage... I would thing WebSQL would accept Blob types and maybe I'm just being lazy about converting blobs, so I'll check that out now.

@jviereck
Copy link
Contributor Author

Personally I am not interested in support Blob, but only ArrayBuffers. If we can get Blob support easy as well, that's great :)

From my research blobs can be stored in websql, but ArrayBuffers can not. There is a way to create blobs from ArrayBuffers, so we could store the arraybuffer as Blob in the websql database. When we call the `getItem(...) method, how could we figure out the stored Blob is supposed to be converted into an Arraybuffer? Store additional meta data in a different websql table could solve this issue.

Matthew Riley MacPherson notifications@github.com wrote:

I'm okay with base64 encodes for localStorage... I would thing WebSQL
would accept Blob types and maybe I'm just being lazy about converting
blobs, so I'll check that out now.


Reply to this email directly or view it on GitHub:
#40 (comment)

Sent from my Android device with K-9 Mail. Please excuse my brevity.

@tofumatt tofumatt added this to the Binary data support milestone Mar 19, 2014
tofumatt added a commit that referenced this issue Mar 19, 2014
Adds support for ArrayBuffer, Blob, and most kinds of TypedArrays
to all drivers. Relies on some hairy code (that could be further refactored)
for localStorage and WebSQL, but the point is everything checks out.

PhantomJS seems to have problems with the Blob test; while I'm hesitant to
skip tests, it DOES work fine in Safari, which is the target there, so I'm
going to look into it but commit this work for now, as it's very useful.

* Fix #28
* Fix #30
* Fix #40
* Fix #63

This partially addresses #69, as it allows for Blob storage, but doesn't
address the issue of extremely large files, which neither localStorage nor
WebSQL will support (their limits are too low).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants