id,summary,reporter,owner,description,type,status,priority,milestone,component,version,resolution,keywords,cc,launchpad_bug 3931,Factor functionality related to running a storage service into a separate class from `_Client`,exarkun,,"`allmydata.client._Client` combines many concerns. At least: * metrics collection * secrets management * webui frontend initialization * storage services * storage client services * blacklist management * file ""node"" creation * helper management * sftp frontend initialization This is just the list that's obvious from reading the names of its methods. Most of the logic for most of these things is already implemented by something other than `_Client`. However, `_Client` ties them all together in an obligatory ""super object"". Much of the functionality can be disabled - but only through the very awkward interface of the bytes in a `tahoe.cfg` file. Instead of making `tahoe.cfg` the only control structure for what `_Client` does and does not do, we should arrange to have a convenient Python API that allows for composition of functionality. For starters, this could exactly mirror the capabilities of `tahoe.cfg` (and should, in fact, be the API that the contents of `tahoe.cfg` drives). The point would be to make it easier to make these choices from Python code - without a trip through an ini-style configuration file. We could start by pulling any one of these pieces out but the storage service piece is particularly interesting as it is undergoing a non-trivial amount of maintenance these days so it makes sense as a starting place for me. This refactoring would make it easier to test existing and new features of the storage system. It should also make the implementation easier to maintain and experiment with in the future. Presently a `_Client` is almost always created by `create_client_from_config` which mediates between `tahoe.cfg` and the current `_Client` Python API. A reasonable goal for this particular ticket could be a refactoring with allows `create_client_from_config` to perform a single, simple composition between `_Client` and an API responsible for the storage service (for example, create the storage service object and pass it to `_Client`, or vice-versa, or pass both to a third thing that does the necessary Twisted `Service` setup, etc). This would replace the current implementation which does some some storage service initialization in `create_client_from_config` _and_ creates a `_Client` _and_ passes some of the storage service values to a method on the partially-initialized `_Client` where there is further `tahoe.cfg` inspection and the rest of the storage service setup process. ",enhancement,new,normal,undecided,unknown,n/a,,,,