Data loss risk if two apps have the same name

[karger]

Because Mavo creates its default storage filename from the name of the app, it is conceivable that two mavo developers will create apps with the same name and storage plugin, which would result in one overwriting the data of the other when both are used by the same user. Since the app name is not even visible to the user, they would get no forewarning.

One solution might be to include the domain name hosting the app, or a hash of it, in the default filename, but this would cause data to be misplaced (though not destroyed) if the app were moved to a new domain.

[LeaVerou]

Two Mavo developers are saving in the exact same place? Could you give me a concrete example?

[karger]

If they both set mv-app="todo" and mv-storage="github"

[LeaVerou]

If they both set mv-app="todo" and mv-storage="github"

And they also haven’t provided a repo name or directory path? 🤔

[karger]

Why would they? Neither is required by default.

[LeaVerou]

What do you propose should happen?

[karger]

I think there are several mechanisms that would prevent accidental collisions.

Unfortunately the simplest would cause a different problem. That would be to include something of the host url in the name of the data file. Either the host url itself or a short hash of it (as medium seems to do for example, I think so that if you later change the title of your post which defines the url, the url doesn't break). The downside of this is that if the user migrated the app to a different location then the data gets lost. Since this is a rare event, it could be addressed through a dialog with the user where you ask where the app used to be and so on. In the most common case (for this problem) of apps that did not specify a storage location, you know that the file is stored in the default mavo directory, so you could give the user a directory browsing interface to let them locate the file they want to open. But this would have to be done every time.

Another option would be to use a hidden field in the data file to store distinguishing information. eg, to add a "$host" property giving the host url of the app. If, when data was loaded, the $host did not match the current host url, the user could be warned that they might be stomping on data from a different app and given the chance to do something else.

In the default case, where the user specifies only a back end but not a file, so the app data gets written into the canonical "mavo" directory, one could also imagine placing this auxiliary information in a general mavo-config file stored in that directory. The mavo-config file could would be read and written by all mavo apps making use of the directory, and would retain information about which mavo app (identified by hostname and mv-app) used which file. This would in some ways be the most powerful, since it would let a user (using a mavo app designed to edit that mavo-config file) specify which file should be used for which mavo app that is using that default location---even when two of them have the same mv-app and are using default locations. Indeed, it would allow people to make arbitrary choices about which data file to use (in the default directory) with which mavo app, and have those remembered so they don't have to choose every time.