Ticket created by ~qeef on ~qeef/damn-project
What? Get rid of docker-compose as basic configuration.
Why? Because it's not ok to rebuild docker image when few lines of javascript client changes.
How? Nginx + some HTTPS + fastapi + alpine + python scripts + PostGIS + cron.
Notes:
- 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.
Comment by ~qeef on ~qeef/damn-project
This is deployed now at https://finished.damn-project.org/
REPORTED RESOLVED IMPLEMENTED
Comment by ~qeef on ~qeef/damn-project
The link above does not work anymore, the script has been merged: https://git.sr.ht/~qeef/damn-deploy/commit/ee526ee4a5ef39bd1b4401ff8773fa59b447e45c
Ticket created by ~qeef on ~qeef/damn-project
In the
staticdirectory of the manager and the client, there isi18n.jsfile with the inclomplete translations.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.
- There MUST be no 3rd party JavaScript library to import/include into the manager nor client.
- 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, wherecsis the language code. 3. After the translation is finished, reply to the mailing list thread with the updatedi18n.jsfile attached, or send the related patch to the mailing list.)
Ticket created by ~qeef on ~qeef/damn-project
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_areas,current_squares, andcurrent_commitstables and store the finished read-only areas (and squares and commits) in them. The database is ready for this, see70_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 torss_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.
Comment by ~qeef on ~qeef/damn-project
REPORTED RESOLVED IMPLEMENTED
Ticket created by ~qeef on ~qeef/damn-project
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.
Comment by ~qeef on ~qeef/damn-project
REPORTED RESOLVED FIXED