devs/cproof
1
2
Fork 1
Code Issues 43 Pull Requests 6 Actions Packages Projects 1 Releases Wiki Activity

Refactor ProfAccount Structure into Smaller Components #81

New Issue
Open
opened 2026-01-27 16:28:36 +00:00 by jabber.developer2 · 0 comments
jabber.developer2 commented 2026-01-27 16:28:36 +00:00
Collaborator
Copy Link

Summary

The ProfAccount structure in account.h has grown to contain 34 fields covering multiple unrelated concerns. This violates the Single Responsibility Principle and makes the codebase harder to maintain and extend.

Current State

The ProfAccount struct currently mixes:

  • Identity fields: name, jid, password, eval_password, resource
  • Connection settings: server, port, tls_policy, auth_policy, client, max_sessions
  • Presence/priority settings: last_presence, login_presence, priority_online, priority_chat, priority_away, priority_xa, priority_dnd
  • MUC settings: muc_service, muc_nick
  • OTR encryption: otr_policy, otr_manual, otr_opportunistic, otr_always
  • OMEMO encryption: omemo_policy, omemo_enabled, omemo_disabled
  • PGP/OX encryption: ox_enabled, pgp_enabled, pgp_keyid
  • Misc: enabled, startscript, theme

Variant of refactoring

Split ProfAccount into smaller, focused sub-structures:

typedef struct prof_account_identity_t {
    gchar* name;
    gchar* jid;
    gchar* password;
    gchar* eval_password;
    gchar* resource;
} ProfAccountIdentity;

typedef struct prof_account_connection_t {
    gchar* server;
    int port;
    gchar* tls_policy;
    gchar* auth_policy;
    gchar* client;
    int max_sessions;
} ProfAccountConnection;

typedef struct prof_account_presence_t {
    gchar* last_presence;
    gchar* login_presence;
    gint priority_online;
    gint priority_chat;
    gint priority_away;
    gint priority_xa;
    gint priority_dnd;
} ProfAccountPresence;

typedef struct prof_account_muc_t {
    gchar* muc_service;
    gchar* muc_nick;
} ProfAccountMuc;

typedef struct prof_account_encryption_t {
    // OTR
    gchar* otr_policy;
    GList* otr_manual;
    GList* otr_opportunistic;
    GList* otr_always;
    // OMEMO
    gchar* omemo_policy;
    GList* omemo_enabled;
    GList* omemo_disabled;
    // PGP/OX
    GList* ox_enabled;
    GList* pgp_enabled;
    gchar* pgp_keyid;
} ProfAccountEncryption;

typedef struct prof_account_t {
    ProfAccountIdentity identity;
    ProfAccountConnection connection;
    ProfAccountPresence presence;
    ProfAccountMuc muc;
    ProfAccountEncryption encryption;
    gboolean enabled;
    gchar* startscript;
    gchar* theme;
} ProfAccount;

Benefits

  1. Improved readability: Related fields are grouped together
  2. Easier maintenance: Changes to encryption logic don't affect connection code
  3. Better testability: Sub-structures can be unit tested independently
  4. Reduced function signatures: account_new() currently takes 33 parameters — sub-structures allow passing grouped config
  5. Future extensibility: Adding new encryption methods only affects ProfAccountEncryption

Migration Steps

  1. Create new sub-structures in account.h
  2. Update account_new() signature to use builder pattern or sub-struct parameters
  3. Update account_free() to handle nested structures
  4. Refactor accounts.c to work with new structure
  5. Update all call sites (search for account-> accessors)
  6. Update unit tests in unittests
  7. Consider creating helper functions like account_encryption_free(), account_presence_init(), etc.

Impact Assessment

  • High impact: Changes touch core account management
  • Files affected: account.c, accounts.c, cmd_funcs.c, xmpp/connection.c, xmpp/session.c, and others
  • Risk: Medium — requires careful migration of all field accesses

Labels

refactoring, code-quality, breaking-change

## Summary The `ProfAccount` structure in account.h has grown to contain 34 fields covering multiple unrelated concerns. This violates the Single Responsibility Principle and makes the codebase harder to maintain and extend. ## Current State The `ProfAccount` struct currently mixes: - **Identity fields**: `name`, `jid`, `password`, `eval_password`, `resource` - **Connection settings**: `server`, `port`, `tls_policy`, `auth_policy`, `client`, `max_sessions` - **Presence/priority settings**: `last_presence`, `login_presence`, `priority_online`, `priority_chat`, `priority_away`, `priority_xa`, `priority_dnd` - **MUC settings**: `muc_service`, `muc_nick` - **OTR encryption**: `otr_policy`, `otr_manual`, `otr_opportunistic`, `otr_always` - **OMEMO encryption**: `omemo_policy`, `omemo_enabled`, `omemo_disabled` - **PGP/OX encryption**: `ox_enabled`, `pgp_enabled`, `pgp_keyid` - **Misc**: `enabled`, `startscript`, `theme` ## Variant of refactoring Split `ProfAccount` into smaller, focused sub-structures: ```c typedef struct prof_account_identity_t { gchar* name; gchar* jid; gchar* password; gchar* eval_password; gchar* resource; } ProfAccountIdentity; typedef struct prof_account_connection_t { gchar* server; int port; gchar* tls_policy; gchar* auth_policy; gchar* client; int max_sessions; } ProfAccountConnection; typedef struct prof_account_presence_t { gchar* last_presence; gchar* login_presence; gint priority_online; gint priority_chat; gint priority_away; gint priority_xa; gint priority_dnd; } ProfAccountPresence; typedef struct prof_account_muc_t { gchar* muc_service; gchar* muc_nick; } ProfAccountMuc; typedef struct prof_account_encryption_t { // OTR gchar* otr_policy; GList* otr_manual; GList* otr_opportunistic; GList* otr_always; // OMEMO gchar* omemo_policy; GList* omemo_enabled; GList* omemo_disabled; // PGP/OX GList* ox_enabled; GList* pgp_enabled; gchar* pgp_keyid; } ProfAccountEncryption; typedef struct prof_account_t { ProfAccountIdentity identity; ProfAccountConnection connection; ProfAccountPresence presence; ProfAccountMuc muc; ProfAccountEncryption encryption; gboolean enabled; gchar* startscript; gchar* theme; } ProfAccount; ``` ## Benefits 1. **Improved readability**: Related fields are grouped together 2. **Easier maintenance**: Changes to encryption logic don't affect connection code 3. **Better testability**: Sub-structures can be unit tested independently 4. **Reduced function signatures**: `account_new()` currently takes 33 parameters — sub-structures allow passing grouped config 5. **Future extensibility**: Adding new encryption methods only affects `ProfAccountEncryption` ## Migration Steps 1. [ ] Create new sub-structures in `account.h` 2. [ ] Update `account_new()` signature to use builder pattern or sub-struct parameters 3. [ ] Update `account_free()` to handle nested structures 4. [ ] Refactor `accounts.c` to work with new structure 5. [ ] Update all call sites (search for `account->` accessors) 6. [ ] Update unit tests in unittests 7. [ ] Consider creating helper functions like `account_encryption_free()`, `account_presence_init()`, etc. ## Impact Assessment - **High impact**: Changes touch core account management - **Files affected**: `account.c`, `accounts.c`, `cmd_funcs.c`, `xmpp/connection.c`, `xmpp/session.c`, and others - **Risk**: Medium — requires careful migration of all field accesses ## Labels `refactoring`, `code-quality`, `breaking-change`
jabber.developer2 added the
Kind/Enhancement
Kind/Testing
 labels 2026-01-27 16:28:36 +00:00
jabber.developer2 added this to the Plans (2025-2026) project 2026-01-27 16:28:36 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Compat/Breaking
Breaking change that won't be backward compatible
Kind/Bug
Something is not working
Kind/Documentation
Documentation changes
Kind/Enhancement
Improve existing functionality
Kind/Feature
New functionality
Kind/Security
This is security issue
Kind/Testing
Issue or pull request related to testing
Priority
Critical
1
The priority is critical
Priority
High
2
The priority is high
Priority
Low
4
The priority is low
Priority
Medium
3
The priority is medium
Reviewed
Confirmed
1
Issue has been confirmed
Reviewed
Duplicate
2
This issue or pull request already exists
Reviewed
Invalid
3
Invalid issue
Reviewed
Won't Fix
3
This issue won't be fixed
Status
Abandoned
3
Somebody has started to work on this but abandoned work
Status
Blocked
1
Something is blocking this issue or pull request
Status
Need More Info
2
Feedback is required to reproduce issue or to continue work
No Label
Kind/Enhancement
Kind/Testing
Milestone
No items
No Milestone
Projects
Clear projects
No project Plans (2025-2026)
Assignees
Clear assignees
admin jabber.developer jabber.developer2
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: devs/cproof#81
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?