search

curiousdannii / parchment

The Interactive Fiction web app
https://iplayif.com
MIT License
430 stars 60 forks source link

Sync savefiles to cloud server #11

Open curiousdannii opened 11 years ago

curiousdannii commented 11 years ago

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

otakup0pe commented 11 years ago

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

curiousdannii commented 2 years ago

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:

MarkLodato commented 9 months ago

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 commented 9 months ago

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 commented 8 months ago

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!