Add "mv-autoload" to parallel "mv-autosave"

[karger]

mv-autosave ensures that I store any changes made in my mavo app. But suppose I am using the app on 2 machines and I forget to load the changed data that was saved from the other? Then I may overwrite the new data. This could be addressed with e.g. mv-autoload="10" saying that whenever 10 seconds pass without any local data changes the back-end should be polled for remote ones and new data loaded if available. I could also imagine combining autosave and autoload with e.g. mv-sync="10"

[LeaVerou]

I like the mv-sync idea. We should come up with nice syntax for:

• When you want to sync in both directions, no throttling
• When you only want to sync in one direction (e.g. only autosave, or only push)
• When you want to sync in both directions, with different throttling

[DmitrySharabin]

What about this one?

• mv-sync — both directions, no throttling — equivalent to mv-sync="save, load"
• mv-sync="2" or mv-sync="2s" or mv-sync="every 2s" — equivalent to mv-sync="save every 2s, load every 2s"
• mv-sync="save" — equivalent to mv-autosave
• mv-sync="save every 2s" — equivalent to mv-autosave="2"
• mv-sync="load"
• mv-sync="load every 2s"
• mv-sync="save every 5s, load every 2s"

Are we going to support other durations: minutes, hours, days, etc.? Suppose we want to load data every 10 minutes. Should we write it like this: mv-sync="load every 600s"? Or this: mv-sync="load every 10m"? Or we'll let authors use expressions (including Mavo functions), like so: mv-sync="load every 10 * minutes()"?

[LeaVerou]

Several thoughts:

• I would be opposed to things like mv-sync="2" as it's cryptic and makes no sense when read.
• We don't need to come up with a whole microsyntax for durations when people can just use brackets and output whatever, e.g. [2 * minutes() + 3 * seconds()].
• save every 2s implies that data is saved every 2 seconds regardless of whether there are changes or not. It's actually "at most every 2s", but that would be too wordy.

[karger]

Agree with Lea that we can just use existing exprs to specify durations.

Should we have mv-sync and mv-save and mv-load? Do they need to be called mv-autosave and mv-autoload for clarity?

[andreasplesch]

If mv-sync and the mv-autosave/autoload pair is available, there is complication from having to resolve conflicts if both are provided and are conflicting ( mv-sync always wins ?). What would be the values for these to disable syncing (presumably the defaults) ? "Never" ? What is the simplest, most explicit representation ?

Should there be an optional push mechanism from capable backends to trigger loading ? autoload="ondemand" ?

[karger]

In general I would assume that more detailed attributes (mv-autosave) would override more general (mv-sync). If we decide to have all of them.

The firebase plugin supports the optional push mechanism through mv-firebase="realtime". Unclear whether there should be a standardized mavo attribute for "accept server pushes" or whether this is so different by back-end that it has to be back-end specific.

[LeaVerou]

I don't see the upside of having two sets of attributes for the same thing, with completely different naming schemes. If we move to mv-sync we should deprecate mv-autosave and NOT introduce mv-autoload (which is a confusing name anyway).

The firebase plugin supports the optional push mechanism through mv-firebase="realtime". Unclear whether there should be a standardized mavo attribute for "accept server pushes" or whether this is so different by back-end that it has to be back-end specific.

I'd imagine mv-sync would handle that and would push on backends that support it, or pull in backends that don't.