Architecture discussion #2

New Issue

sashakoshka · 2024-02-08T11:22:32-07:00

sashakoshka commented

2024-02-08 11:22:32 -07:00

How should this software work?

Some ideas:

Self contained, like Gitea
Front-end for Unix
- Central server for displaying public read-only information?
- A user-level daemon, spawned for each participating user, providing a web interface for managing repositories you own?
- Both at the same time? Neither?
- Federation through AP/forgefed

How should this software work? Some ideas: - Self contained, like Gitea - Front-end for Unix - Central server for displaying public read-only information? - A user-level daemon, spawned for each participating user, providing a web interface for managing repositories you own? - Both at the same time? Neither? - Federation through AP/forgefed

sashakoshka added the

enhancement

label 2024-02-08 11:22:32 -07:00

sashakoshka referenced this issue from sashakoshka/mintea

2024-02-08 11:22:58 -07:00

Architecture discussion #1

emma commented

2024-02-11 13:29:26 -07:00

pros of Unix users:

no database for users
repos are just files in users’ home directories

cons of Unix users:

mintee has to read from users’ home directories
they are decoupled from other kinds of users (activitypub, e-mail-only)

pros of database:

tried and tested
unified view of all users

cons of database:

database wrangling
another dependency

pros of Unix users: - no database for users - repos are just files in users’ home directories cons of Unix users: - mintee has to read from users’ home directories - they are decoupled from other kinds of users (activitypub, e-mail-only) pros of database: - tried and tested - unified view of all users cons of database: - database wrangling - another dependency

emma commented

2024-02-11 13:31:05 -07:00

Alternatively, we could assign directories to specific Unix users under /srv/git (like /srv/git/emma) and they could manage that however they wanted that way.

Alternatively, we could assign directories to specific Unix users under `/srv/git` (like `/srv/git/emma`) and they could manage that however they wanted that way.

sashakoshka commented

2024-07-03 00:17:41 -06:00

Me and Emma were brainstorming the other day and here are the highlights, plus some other details I've thought of in the meantime:

Aggressive modularization of the service

We can divide the system into functional modules (likely implemented as separate daemons), so that if one part experiences issues it doesn't cause a catastrophic failure of the entire system. For example, if the web UI went down, cloning/pushing to repositories could still work. This would be quite helpful for Go projects in particular, due to the way that Go modules work.

Store data using dirs/files

Doing this is more transparent than a database, and allows us to more easily edit the data by hand if something fails. Additionally, we get event subscription for free (i.e. inotify). This would allow the different parts of the service to communicate with each-other without needing much message passing IPC, if any at all. Git repositories are also implemented in a similar way and would fit into this system very cleanly.

Backwards compatibility

The whole gitea/forgejo indecent was caused by gitea upgrading the database in a way that forgejo could not understand. v1.0.0 needs to be stable, and we can't go restructuring data like that after we reach that version.

Me and Emma were brainstorming the other day and here are the highlights, plus some other details I've thought of in the meantime: ## Aggressive modularization of the service We can divide the system into functional modules (likely implemented as separate daemons), so that if one part experiences issues it doesn't cause a catastrophic failure of the entire system. For example, if the web UI went down, cloning/pushing to repositories could still work. This would be quite helpful for Go projects in particular, due to the way that Go modules work. ## Store data using dirs/files Doing this is more transparent than a database, and allows us to more easily edit the data by hand if something fails. Additionally, we get event subscription for free (i.e. inotify). This would allow the different parts of the service to communicate with each-other without needing much message passing IPC, if any at all. Git repositories are also implemented in a similar way and would fit into this system very cleanly. ## Backwards compatibility The whole gitea/forgejo indecent was caused by gitea upgrading the database in a way that forgejo could not understand. v1.0.0 needs to be stable, and we can't go restructuring data like that after we reach that version.

emma commented

2024-07-03 15:39:00 -06:00

I want to allow anonymous users for sure