Skip to content

Instantly share code, notes, and snippets.

@wlach
Created April 2, 2021 12:27
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save wlach/97ed10d1be48656176727b0332e61824 to your computer and use it in GitHub Desktop.
Save wlach/97ed10d1be48656176727b0332e61824 to your computer and use it in GitHub Desktop.
iodide-saving-wishlist.iomd
%% md
# Iodide saving short-term wishlist
The current implementation of autosave is pretty decent for our immediate use cases, but could use a number of refinements:
* Infrequent server autosaves - the recent push to save when the iodide tab loses focuses helps, but it would probably still be good to autosave a little more frequently if we can, especially if the above issue is fixed. Maybe once every 15 or even 10 seconds?
* Allow explicit saves again. On second thought, I think it's nice to have an explcit way to save for the impatient and/or paranoid. We could do something like what glitch does and say `(P.S.: iodide autosaves!)`. See [#1586](https://github.com/iodide-project/iodide/issues/1586)
# Resolved issues
* Allow reverting to a previous revision directly from the in-notebook revision browser
* Useless empty "Unsaved changes" revision in the in-notebook revision browser
* The current consistency check should catch most cases of "the user edited the notebook from another tab", but we should be extra careful here and also submit the revision that we're on when saving. [#1569](https://github.com/iodide-project/iodide/issues/1569)
* Allow making an historical revision the current one (e.g. by force-overwriting the autosave)
* We do not save the title in local autosave. See [#1599](https://github.com/iodide-project/iodide/issues/1599)
* Error handling when the logged-in session is lost. See [#1680](https://github.com/iodide-project/iodide/issues/1680)
* General cleanup (some of the code is still a bit messy and/or isn't 100% clear). We should especially make sure all error cases are handled correctly.
* Excessive number of revisions - because we save every 30 seconds if there are changes, the number of active revisions can grow very quickly. We should probably cap the number of revisions at something like once per minute after 5 minutes, maybe even less.
# Saving hypotheses
* If the user hasn't made any modifications locally,
it is ok (desirable!) to just go ahead and update it to the latest version of the notebook when they switch back to it
* If the user *has* made local modifications that haven't been synced, what to do depends
on whether their current login state.
* if they are logged in and this is their notebook (this is quite unlikely to happen): we should give them the option to either make this the new head revision or to revert to the one on the server. document should be read-only until they make a choice, so they don't clobber their work. this also goes for the case where the user
is viewing an old notebook
* if they aren't logged in or this isn't their notebook: notify them that this is an old revision but otherwise don't interfere with their ability to edit it
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment