Storing code on disk
paulsonnentag opened this issue · comments
If we adopt the "claims and wishes" system in Paper Programs more and more of the code should be moved to actual papers. I feel slightly uncomfortable storing all my code in the database. I think it's better to store the files on disk. That way it's very easy to backup / version code. It's also easy to browse the state of the system and use any existing coding tools if necessary. It would also make sharing code digitally more easy. Right now I see a usage pattern where I write code inside paper programs and then also copy it to a file so I can share it with others and have it savely stored.
I propose the following folder structure where each space has its own subfolder modified programs have two files the original file with the name {number}.js and _{number}.js for the modified version which would be actually executed.
-- programs
|
-- space1
| |
| -- 1.js // printed version
|
-- _1.js // current temporary version prefixed with
What are your thoughts about this?
Do we want programs to have unique numbers across all spaces, or do we care that each space have its own numbering system and use a separate identifier to share programs across spaces? The current global limit/numbering system is clearly insufficient. Are we ready to commit to a numbering system going forward without easily allowing for changes in the future?
What if there was a separate id (hash like with git?) that is used for the filename if programs are stored on-disk, and the mapping between programs and the local numbering used by the visual recognition system is stored in the local database.
Great suggestion @paulsonnentag! I'm super down for doing that. In that case we could even get rid of postgres and just use an in-memory database instead, which would simplify things.
As for your numbering point @cesmoak, we currently do need a simple numbering system for the papers, as you cannot make that many combinations with just coloured dots. So since we're limited by that numbering system per space, I think it makes sense to store them on disk like that (scoped by space id, like @paulsonnentag proposed). Maybe we should write a "publish" feature to publish programs to git or gists or so? For that I think it would make sense to use git hash as an identifier.
I'm wondering how they are doing it at Dynamicland because they don't seem to be so worried about the number of papers and they have at least ~18.000. I'd be curious as well why you have the restriction that each corner needs 4 unique colors.
Yeah I'm just bad at writing image detection algorithms I guess. I wrote it so that every corner is unique. They're not doing that. But it helps a lot for redundancy with my terrible algorithm. Same for the 4 unique colours.