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

Usage in web workers #264

Closed
icidasset opened this issue Oct 4, 2017 · 4 comments
Closed

Usage in web workers #264

icidasset opened this issue Oct 4, 2017 · 4 comments

Comments

@icidasset
Copy link

Moving stacks-archive/blockstack-storage-js#12 over.

So essentially the issue is that the main browser thread hangs when you run putFile, and the bigger the data the longer it hangs. This might not be really noticeable if the data you store is small, but for my application, it can be quite big. For example, I have almost 10000 tracks in my Ongaku Ryoho app which is like almost 6MB or something.

That said, you can get around this issue by using web workers (which is a separate thread). This library currently can't be used in web workers because it tries to get stuff out of localStorage, which is not available in web workers. So a fix would be to pass in all necessary data via the function's arguments. Kind of which you're already doing here -> https://github.com/blockstack/blockstack-storage-js/blob/feature/multi-reader-storage/src/api.js#L772 But more extensively, because this doesn't work if you don't have a username. Anyhow, you get the point 😅

Let me know what you think and if I can help in any way.
Thanks for the hard work you guys!

@larrysalibra
Copy link
Contributor

Thanks @icidasset.

Speaking of large files, I'm also wondering how our encryption that @kantai is working on in #261 #262 will affect storage.

This library currently can't be used in web workers because it tries to get stuff out of localStorage, which is not available in web workers.

I think we're in general agreement in the core team that this library shouldn't be storing state anywhere (especially without telling app developers) and instead letting apps handle that as they please. Your trouble with web workers is another example of why we shouldn't be doing this. See #265

Kind of which you're already doing here -> https://github.com/blockstack/blockstack-storage-js/blob/feature/multi-reader-storage/src/api.js#L772 But more extensively, because this doesn't work if you don't have a username.

Multi reader storage will likely never work without a username. :-/ Without a username there's no easy way to discover the other user and their various devices.

We should definitely address this before a 1.0 release goes out - I'm not sure if we're going to have time to address in the next couple weeks.

@icidasset
Copy link
Author

That'd be great @larrysalibra
I'll be following #265 closely then, let me know if I can help.

Oh ok, makes sense. So if I don't have a username, can I still use storage without exposing my data to other people/devices? Or will the username be a requirement in the future? I'm asking because I don't own any bitcoin and as a consequence no username. Coinbase is being a **** and it doesn't let me buy stuff with my creditcard 😓

Thanks!

@larrysalibra
Copy link
Contributor

Or will the username be a requirement in the future? I'm asking because I don't own any bitcoin and as a consequence no username. Coinbase is being a **** and it doesn't let me buy stuff with my creditcard 😓

In the near future we'll be releasing the ability to register free "subdomain" usernames: something like larry.blockstack.id - you won't need to pay for these.

@larrysalibra
Copy link
Contributor

I'm going to close this out in favor of #265

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

2 participants