meta/mintee
5
0
Fork 0
Code Issues 10 Pull Requests Projects Releases Activity

Architecture discussion #2

New Issue
Open
opened 2024-02-08 11:22:32 -07:00 by sashakoshka · 5 comments
sashakoshka commented 2024-02-08 11:22:32 -07:00
Owner
Copy Link
Copy Source

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
emma commented 2024-02-11 13:29:26 -07:00
Owner
Copy Link
Copy Source

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
Owner
Copy Link
Copy Source

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
Author
Owner
Copy Link
Copy Source

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
Owner
Copy Link
Copy Source

I want to allow anonymous users for sure

I want to allow anonymous users for sure
sashakoshka commented 2024-07-03 20:57:36 -06:00
Author
Owner
Copy Link
Copy Source

One proposed architecture: #4

One proposed architecture: #4
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Something is not working
 duplicate
This issue or pull request already exists
 enhancement
New feature
 help wanted
Need some help
 invalid
Something is wrong
 question
More information is needed
 wontfix
This won't be fixed
No labels enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
emma (Emma Tebibyte) sashakoshka (Sasha Koshka) silt (silt!) soup (Soup For My Family) trinity (dtb)
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: meta/mintee#2