What? Get rid of docker-compose as basic configuration.
How? Nginx + some HTTPS + fastapi + alpine + python scripts + PostGIS + cron.
- Merge upkeep and gen functionality, rewrite to Python.
- Use alpine, all dependencies available?
- Docker-compose may be provided but as the secondary solution, maybe in another repository.
This is deployed now at https://finished.damn-project.org/
The link above does not work anymore, the script has been merged: https://git.sr.ht/~qeef/damn-deploy/commit/ee526ee4a5ef39bd1b4401ff8773fa59b447e45c
There are few things to do:
- check and refactor/simplify the strings,
- add the missing strings & update related code,
- think about how to translate the strings.
The first two points are clear. There are some points about the third one:
- It would be beneficial to use some 3rd party platform that is already used by translators. If used, the platform SHOULD be FOSS, open, etc.
- The translated strings MUST be available for the offline usage. (To keep the download client functionality.)
- The translated strings MUST be available under some compatible license.
- It would be beneficial to allow translations by sending an email to the mailing list, either as a patch or an attached file. (The proposed workflow is: 1. Check the mailing list archive if the translation already exists. 2. Send an email to the mailing list about your intention to work on some language with the subject of
I will work on cs translation, where
csis the language code. 3. After the translation is finished, reply to the mailing list thread with the updated
i18n.jsfile attached, or send the related patch to the mailing list.)
Since the beginning of the damn project, it is ready for two kinds of areas -- current and finished. The original idea was to have the "clones" of
current_commitstables and store the finished read-only areas (and squares and commits) in them. The database is ready for this, see
70_damndb.sqlof the damn-deploy repo.
However, there are two main disadvantages of this approach: (1) There must be an API to retrieve the data from the database basically duplicating and/or complicating the code of the damn-server repo; (2) the database has to serve static, read-only data. Both are against the damn project philosophy, particularly the simplicity (1) and the performance (2).
The proposed solution is to create new service (or even better--update
upkeepservice) similar to
rss_genof the damn-deploy repository that would (1) create static file containing finished area, it's squares, and commits, (2) delete the finished area, it's squares, and commits from the database, (3) serve the static file at some subdomain.
Create service that loads all (new) commits for all (new) areas and provides filtered RSS feeds.
The feeds are:
- Area change commits of all the areas.
- Area change commits of one area.
- Some square related commits of one area.
In future versions, support filtering by area tags, priority, description language, and area location.
NOTE: The list of the feeds is intentionally limited (but extendable!) RSS is for human. If some script needs all the information, it's better to use API directly.