Have you ever wonder, why we have satellite-modular or even storagenode-modular? Why not just have a single satellite binary?
I mean, a single binary work too, that is if you want to have 50+ binaries to work with and who know how many more will come.
Introducing mud[1].
What is mud? What does it do?
In practical term, you can change satellite services behavior with --components flag, specifically: you can include/exclude components at runtime, or even use a different implementation to a problem.
This is particular important with ranged-loop. Normally, ranged-loop service would do nothing, unless you force it to do something via --components. (Unlike most of our previous tutorials).
Okay, got the general idea, how can I list which component I could use for a command?
Hmm… you can’t, technically there is, but realistically, this is a tool for developer who already know what they gonna do, not an exploration tool for operator, you have to read code to know which component you can use.
That said, because I already go through it once, I could give you some direction (and you have to read code or ask AI to explain it to you).
Keyword that actually matter: mud.RegisterInterfaceImplementation, mud.Optional (for ranged-loop - most thing are optional and won’t get run by default), mud.Implementation.
Can I not read it?
You don’t have to for now, I’m gonna do it for the next tutorial anyway, but this is one of the core concept of StorJ source code, the source code will change and this tutorial will not last forever..
See you on part 11 where we will dive deep into ranged-loop.