Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
biboumi
biboumi
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 90
    • Issues 90
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 7
    • Merge Requests 7
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • louiz’
  • biboumibiboumi
  • Issues
  • #3386

Closed
Open
Opened Oct 09, 2018 by louiz’@louizMaintainer

Refactor resources handling

Currently, the way we store “what resources is in what server” and “what resource is in what channel” is very messy.

Main reason being that I wanted to store all that in Bridge. I didn’t want to include the concept of “resource” (which is a XMPP notion) in the IRC (server or channel) code. That was justified, in my mind, by a clear separation of concern: IRC code should not be aware of anything XMPP-related, and XMPP should not be aware of anything IRC-related.

I think it’s time to change that. It makes things complicated for almost no gain (a Resource is just a std::string, we don’t need to import any huuuge class definition in the IRC code), because the Bridge has to maintain many lists of things that it already stores (the list of servers, which contain a list of channels).

And this becomes even more complicated if we try to implement #3353 (closed), because we need to store yet an OTHER list of things in Bridge: what resource is actually force-connected.

So, before I do any more work on #3353 (closed), let’s just clean here by storing resources inside IrcClient and IrcChannel, to make the code a lot simpler, cleaner and reliable (because, yes, it makes bugs very very easy to introduce; as I discovered myself…)

Edited Oct 09, 2018 by louiz’
To upload designs, you'll need to enable LFS and have admin enable hashed storage. More information
Assignee
Assign to
10.0
Milestone
10.0
Assign milestone
Time tracking
None
Due date
None
Reference: louiz/biboumi#3386