Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modularize IPv8 community loading #5593

Closed
qstokkink opened this issue Oct 1, 2020 · 4 comments · Fixed by #5597
Closed

Modularize IPv8 community loading #5593

qstokkink opened this issue Oct 1, 2020 · 4 comments · Fixed by #5597
Assignees

Comments

@qstokkink
Copy link
Contributor

As the Tribler repository now features an experiment/ folder, we are seeing the same staging procedures being implemented as already available in Gumby. One of these features is the staging of IPv8 communities. In order for both repositories to benefit, I propose moving this from Gumby into the Tribler experiment infrastructure.

Loading communities in the Session is currently one big line of if .. else statements, see https://github.com/Tribler/tribler/blob/devel/src/tribler-core/tribler_core/session.py#L146
Instead, in Gumby, this is completely modularized, see https://github.com/Tribler/gumby/blob/devel/gumby/modules/gumby_session.py

This modularization of loading communities improves the Tribler code in four ways:

  • It shortens the Session code (making it more of a manager and less of a god class).
  • Allows for isolation and staging of community loading.
  • Reduces the complexity of staging components.
  • Allows for declarative programming.

There is also a downside: a big if .. else construction is slightly faster than a modular loading system. But, considering the direction we are heading, that seems like an acceptable sacrifice.

@devos50
Copy link
Contributor

devos50 commented Oct 1, 2020

I think this would be a good idea to avoid further code duplication. I wonder though if Gumby can be split in such a way that we move the community loading stuff to Tribler, and leave infrastructure-related code in a separate repository. Or maybe we should just move the entire Gumby code base in the Tribler repository?

@qstokkink
Copy link
Contributor Author

qstokkink commented Oct 1, 2020

To be honest, Gumby is like bringing a nuclear bomb to a knife fight. It is hard to control and too fat for the type of experiments in Tribler (based on #5580 and #5589).

My intention with this issue is to bring the functional components of Gumby into Tribler, so we can have lean and mean experiments in the Tribler repository. While, at the same time, leaving Gumby as the all-powerful alternative for mass deployment of isolated experiments.

Concretely, @devos50: yes we can definitely make this split, but moving the entirety of Gumby into Tribler is also probably not what we need (or want).

@ichorid
Copy link
Contributor

ichorid commented Oct 1, 2020

Related to #4953 #3896 #2029

@qstokkink
Copy link
Contributor Author

I guess I can do this today.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging a pull request may close this issue.

3 participants