[WIP] Replace the service builder with an experimental builder trait #6600
Conversation
| let (block_import, grandpa_link) = | ||
| import_setup.take() | ||
| .expect("Link Half and Block Import are present for Full Services or setup failed before. qed"); | ||
| pub fn new_full(config: Configuration) -> Result<TaskManager, ServiceError> { |
There was a problem hiding this comment.
If I understand the idea correctly. It means you can move the content of that function to fn build_full(config) in the Builder impl below, right?
There was a problem hiding this comment.
This looks very cool imo. Nice API! Maybe Basti will have more insights on this but I think this is what we need.
| @@ -68,8 +69,7 @@ pub fn run() -> sc_cli::Result<()> { | |||
| Some(subcommand) => { | |||
| let runner = cli.create_runner(subcommand)?; | |||
| runner.run_subcommand(subcommand, |config| { | |||
| let (builder, _, _) = new_full_start!(config); | |||
| Ok(builder.to_chain_ops_parts()) | |||
| crate::service::Builder::build_ops(config) | |||
| }) | |||
| } | |||
| None => { | |||
There was a problem hiding this comment.
And then here you can call Builder::new_light and Builder::new_full instead of having functions, right?
| runner.run_subcommand(subcommand, |config| { | ||
| let (builder, _, _) = new_full_start!(config); | ||
| Ok(builder.to_chain_ops_parts()) | ||
| crate::service::Builder::build_ops(config) |
There was a problem hiding this comment.
I realize now that subcommand and ops are actually tight together and should probably share a name. Maybe we should rename run_subcommand to run_ops.
More context/info and thought: "ops" or something else, it doesn't matter much but it must clearly identifies the builtin operations we can do on the chain. The word "subcommand" is more generic and cli-oriented. run_subcommand is not actually used to run "any" subcommand, it's only for ops subcommands. Extra subcommands use run_sync and run_async
|
Closing for the time being due to #4587 (comment). |
|
(If you plan to re-open you can use the tag "onice" instead) |
I mentioned here: #6557 (comment) that I had an idea of how we could build the service in a different way. This PR is my progress so far on this idea. The basic idea is that we have a
sc_service::builder::Buildertrait, which we implement for each chain, e.g.node-template. This trait consists of a lot of type definitions:Builderhas 3 provided functions:build_light,build_full,build_ops. These use the type definitions to build the service components.The biggest advantage of a system like this is that if you're happy with the provided builders, the amount of code you have to write is very small, but if you're not, you only have to re-write the parts you're interested in.