Makes sense to me. Also for production, I would have the app change its name by adding a datetime to the filename, indicating when it was last synchronized.
This is a very appealing idea, I too hope it gets 1000% more attention and adoption.
There are applications where you want to run multiple instances but also want to have them use shared state, e.g. for their preferences (editable via their UI).
Or think of an editor or something like Excel. You probably don’t want the files you edit to all be stored in the binary and require separate export/import functions for sharing, or for editing using alternative applications.
And in the end, that goes for pretty much all data. The applications are the tools you use to view or modify the data, but the data remains independent.
local appConfig[myUniqueArgv0] = { .. some config data .. }
Seems viable to me. I have no problem with different apps having access to each instance' unique app configuration - could be handy for a lot of things. "Copy system config", "Reset to config <blah>", etc.
Comments
$ cp /original/binary.app /new/binary.app && /new/binary.app
Makes sense to me. Also for production, I would have the app change its name by adding a datetime to the filename, indicating when it was last synchronized.
This is a very appealing idea, I too hope it gets 1000% more attention and adoption.
There are applications where you want to run multiple instances but also want to have them use shared state, e.g. for their preferences (editable via their UI).
Or think of an editor or something like Excel. You probably don’t want the files you edit to all be stored in the binary and require separate export/import functions for sharing, or for editing using alternative applications.
And in the end, that goes for pretty much all data. The applications are the tools you use to view or modify the data, but the data remains independent.
On phones we do all use the model that the data is part of the app.