Organize code better #106

New Issue

oysteikt · 2025-11-25T08:20:00+01:00

oysteikt commented

2025-11-25 08:20:00 +01:00

The current codebase is riddled with long similar names both for functions and types, and which file something ends up in seems almost arbitrary sometimes. This should be organized a lot better.

For the general module structure, maybe something like this would be good:

core
- protocol
  - server_to_client
    - data structures
    - errors
  - client_to_server
    - data structures
    - static validation (mostly important for server for security, but should be used client side as well to save traffic)
- config
  - parsing
  - static validation
- privilege logic
  - data structures for privilege tables and diffs
  - logic for reducing diffsets
  - cli arg serialization/deserialization
  - editor serialization/deserialization
- SUID/SGID bootstrap
- utils
client
- arg parsing
- server connection
- mysql_admutils
- commands
server
- arg parsing
- watchdog + supervisor (graceful shutdown)
- authentication and authorization handler
- system status & setup diagnostics
- server loop
  - listen with different types of sockets
  - handling of database connection pool
  - session handler
- sql
  - dynamic validation of protocol data against database
  - row serialization/deserialization (from protocol data structures)

It's not completely correct to put cli/editor serialization/deserialization in the core logic, but it takes up a bunch of space and the formats are closely releated to the datastructures, so that will be an exception

As a general rule of thumb, the stuff in core should be unit tested.

The current codebase is riddled with long similar names both for functions and types, and which file something ends up in seems almost arbitrary sometimes. This should be organized a lot better. For the general module structure, maybe something like this would be good: - core - protocol - server_to_client - data structures - errors - client_to_server - data structures - static validation (mostly important for server for security, but should be used client side as well to save traffic) - config - parsing - static validation - privilege logic - data structures for privilege tables and diffs - logic for reducing diffsets - cli arg serialization/deserialization - editor serialization/deserialization - SUID/SGID bootstrap - utils - client - arg parsing - server connection - mysql_admutils - commands - server - arg parsing - watchdog + supervisor (graceful shutdown) - authentication and authorization handler - system status & setup diagnostics - server loop - listen with different types of sockets - handling of database connection pool - session handler - sql - dynamic validation of protocol data against database - row serialization/deserialization (from protocol data structures) It's not completely correct to put cli/editor serialization/deserialization in the core logic, but it takes up a bunch of space and the formats are closely releated to the datastructures, so that will be an exception As a general rule of thumb, the stuff in `core` should be unit tested.

oysteikt added the techdebt spring cleaning label 2025-11-25 08:20:00 +01:00

oysteikt added reference cleanup-code-structure

2025-11-25 18:03:32 +01:00

oysteikt commented

2025-11-25 19:25:14 +01:00

Partially merging this by rebasing following commits onto main:

805c2d11ff
c9815fe7de
1571f6e2c7
9e39401049
4fb60f8563

Partially merging this by rebasing following commits onto main: 805c2d11ff95fc96f43f56eaea4d1a2634d0d74d c9815fe7debdbb3853b9938bb877d3ecb4e79d00 1571f6e2c7303e4752a87629fa6d1b9398c1284d 9e394010492beb300c36bbb544129ec3fbc8fb17 4fb60f8563ae7a0468f340165438ac37e190b801

oysteikt commented

2025-12-03 05:49:52 +01:00

I think this is kinda done now, it's much better than before. Maybe some renaming of the privilege stuff should be done, but that can be taken up later

oysteikt closed this issue

2025-12-03 05:49:52 +01:00

oysteikt added this to the Initial release milestone 2025-12-03 05:50:11 +01:00

Sign in to join this conversation.

No Assignees

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Projects/muscl#106