I would like to have a Snap! command (i.e. as part of the language) that will save the current state of a project. Like the Save menu option, and in accordance with @bh’s reputed “Eisenberg’s law”.
Why?
To have a process run in the background that will, e.g. every five minutes, save the project while it is being edited - this is important especially on a somewhat unstable platform like iOS.
If a project runs for a long time, like hours or days on end, there is a serious risk of it crashing. If it regularly saved itself it can easily be (almost completely) restored.
There are already times when we run out of server bandwidth. So if you want this feature, I think you have to start by getting some rich person to endow a fund that will permanently support a much wider pipe, including provision for growth in the user community.
I support this, sometimes seemingly randomly the top buttons stop working and I can’t drag blocks anymore. So all I would need to do in that situation is wait for an auto save
Also maybe pressing the “restore” button could restore the last manual save you did so that it doesn’t auto save in a bad spot where you accidentally deleted an important piece of code
I think the Snap! servers wouldn't be able to handle the workload if this were a thing. Snap! attempts to block scripts that save the project. Sometimes, The server has short downtimes with people trying to get onto the site.
IMO one doesn’t need to save a project too often. I’d say once every five minutes or so (and only if any edits were made). Besides one could build the AUTOSAVE function such that data are saved even less often (up to once every half hour) if the server is apparently rather busy (as derived from save durations). One could also take the number of edits into the equation..
But then there would be restrictions causing new people to make more posts on the forum just how to save a project with a block. Besides? Why a block? Why not just have a setting with a minimum time limit like every 7 minutes or something.
We would like to find a way to do it that doesn't use up server bandwidth or virtual disk storage. We can't get something for nothing, but probably there are ways to be more efficient than just doing straightforward saves. Here's a probably-stupid idea off the top of my head: When you load a project and then edit it, your client remembers the state of the project when you loaded it. Then when you save, the client just sends the server differences (and updates the remembered state).
But it's okay that my idea is probably stupid, because I'm sure real computer scientists have figured out clever ideas we can use. :~) We know that people want autosaving, for good reasons. I don't think we should do Google Docs-style autosaving, which actually updates your file, so you never have to save explicitly. Rather, we should declare autosaving to be just for error recovery, so you have to do something explicit to load an autosaved project, and a regular load gets the last version of the project that you explicitly saved. This is important because those versions have consistent values of all the project's state variables.
Anyway, I think we all want to figure this out eventually. But, as always, don't hold your breath.
O, wow … so if, using @dardoro’s block, I make my project save itself as a local backup in my browser every few minutes, I can restore it after a crash. And the whole procedure will not cause extra load on the Snap! server. Sounds great, I’m definitely going to try this for at least a few days to experience if there are any downsides to this scheme - are there?
Just one little detail to keep in mind: Don't start autosaving until you've actually edited something, because when you load a project in the same client that already had a project loaded, Snap! saves the old project locally, and you can restore it if you do so before editing the new project.
The number of unsaved changes is counted. If a function of elapsed time and unsaved changes reaches a threshold, the project is locally saved to the browser. Thus it's not asking too much capacity of anything, I guess, and still hardly any changes will ever get lost.
The following is a script that needs to be started manually (or it can be defined as a command block):