Is there any alternative to cloud variables? Thank you.
Not in Snap!. You could build your own web server. Maybe we'll get around to it eventually but there's so much more urgent to do on our server I wouldn't hold my breath.
I see. I will be looking forward to see you people officially launch it. Could the one created by @fsul be useful? Thank you.
There is an alternative: WebRTC.
I really hope if you guys do add it you don't run into Scratch's problem i.e. having WAY too many users on the server using so many cloud variables that you had to limit the server.
I wonder if there is a way to bypass this...
Depends how much effort we want to put into this. We could make you store your cloud variables to your Dropbox account, or something like that.
I'm more worried about it turning into a backdoor for porn on our site.
Then you would need people to hit the report button.
um... what if we don't have one and we don't want to get one?
That was just an example of an idea for outsourcing storage. Do you have a Google account? We might use Google Drive, too.
Why do you really need to store it?
Who's "you"? I'm not someone who wants this feature; I'm just suggesting a way we could allow essentially unlimited Snap! storage, at the user's own cost. I'm not trying to store anything.
By "you" I mean you people.
I'm not part of "you" if you mean people who want cloud variables. I'm just trying to be helpful in suggesting ways they might be implemented -- perhaps even entirely in user code, using APIs of cloud storage providers.
I wouldn't keep going back and forth about this, except that your message
was addressed specifically to me. (That's what the "Reply" button within a message means, as opposed to the red "Reply" button at the bottom, which replies to the thread as a whole.)
I don't see
It's blue if you use the light theme (like I do).
I found it.
I just submitted a workshop for the next Snapcon to offer a solution for this request : cloud variables. They are variables so they have limited life time and not mean't to be stored any where, but to be consumed. And this will be my proposed topic for June.
By the way I'm submitting a pull request for a library extension to handle such issue and more.