Macbi wrote:How exactly would I upload this to Shinjuku/Catgolue?
That's a good question. Currently there isn't a method for uploading syntheses, but I think something like this could work:
- User posts an RLE of well-separated syntheses via a text box on Catagolue (the same way comments are made).
- Catagolue checks that the RLE is well-formed (the only non-blank lines are comments, followed by the RLE header, followed by RLE data lines), that the only characters present in the data lines are [0-9ob$!], that there are no substrings of 5 or more consecutive digits, and that the population does not exceed 100000. (These are basically to prevent 'RLE bombs' such as "9999999999999o!" from breaking the process downstream.)
- If these basic checks pass, the RLE is uploaded into an 'RLE queue'. Otherwise, the user is informed of the syntax error.
This is maximally user-friendly (compared with requiring syntheses be submitted as Shinjuku lines), because it doesn't require the user to have any software other than an RLE editor such as Golly.
Then, when the Catagolue update process runs (as it does automatically every morning), it does the following in order:
- Downloads a file called 'contrib.sjk' (initially an empty file) from Catagolue;
- Downloads the oldest n RLEs from Catagolue's RLE queue;
- Parses these RLEs into Shinjuku format, discarding any invalid lines;
- Appends these lines to contrib.sjk;
- Removes any duplicate lines from contrib.sjk, along with any lines that already occur in Shinjuku's git repository;
- Uploads contrib.sjk to Catagolue, overwriting the existing one;
- Deletes the oldest n RLEs from Catagolue's RLE queue.
This is foolproof from a transactional perspective: the only way RLEs can be deleted is when all of the other steps succeed, and the only way contrib.sjk can lose lines is when they're present in the Shinjuku git repository. The file contrib.sjk will be publicly-readable, so it's possible for Freywa (or anyone else with repository access) to occasionally download it and incorporate it into the repository; the next time the update process runs, the deduplication will ensure that the lines added to the repository will be removed from contrib.sjk, so it won't expand limitlessly.