Sync savefiles to cloud server

[curiousdannii]

It would be amazing to one day be able to sync savefiles to a cloud server

[otakup0pe]

As long as this is optional ! I can imagine some cases where people would want parchment to be completely standalone.

[curiousdannii]

I've been slowly working towards this for a long time, and there's a long time still to go. To enable any cloud syncing services the whole VM ecosystem needs to become asynchronous. Here's a checklist:

• Async GlkApi
• Async Dialog
• For Emglken interpreters, will need a new async FS using WASMFS (WasmFS: Asyncify support for async backends emscripten-core/emscripten#16053)
• Update/rewrite ZVM and Quixe to be async

[MarkLodato]

It sounds like the feature described here would be a seamless "sync" between instances across a cloud server, i.e. a "terp-managed save" as per https://eblong.com/zarf/glk/terp-saving-notes.html.

What about a smaller feature that is simply the ability to save to / restore from Cloud servers or even local storage, i.e. a "player-managed save"? That seems like it would be easier to implement and would provide 95% of the value. Even if the storage APIs are asynchronous, you could just block during the save/restore operations. Does that sounds doable?

*Edit: added links to terp-saving-notes.html"

[curiousdannii]

Zarf's phrase "terp-managed save" is what we more frequently call autosaves, and that's not as directly in scope here. (I was intending for autosaves to be device specific, but it would still be good to have IndexedDB for autosaves.) This issue is primarily about manual player saves.

Parchment already supports saving to localStorage.

Even if the storage APIs are asynchronous, you could just block during the save/restore operations.

Unfortunately you can't "just block" in Javascript.

[curiousdannii]

So I've just realised that if we can patch all the interpreters to only access files via the Glk or glkunix APIs (like glkunix_stream_open_pathname_gen), then we won't need to wait for Emscripten's AsyncFS to be finished. Indeed avoiding all true FS code like that will be both simpler and probably more performant and file size efficient!