Change Config and UserConfig to allow recursive nesting of dictionaries #4574
Labels
part: misc framework
Issue/PR for general applications for Flower framework.
state: stale
If issue/PR hasn't been updated within 3 weeks.
type: feature request
This issue or comment suggests an additional feature.
Describe the type of feature and its functionality.
Currently both Config and User config are defined as arbitrary dictionaries with string keys and Scalar values. This requires the user to have knowledge of what the string keys are in order to access the values they packed into the config. Why not allow the values to also include dictionaries so long as the end values are always Scalars. This can be done with a recursive typing definition. It would allow more organized config and userconfig dictionaries. Furthermore we have a specific use case where we need to pass a highly nested dictionary loaded from a json file from the server to the client. There are too many key-value pairs to make it worth it to unnest the whole thing. Right now we are getting around it by serializing the dictionary so that it can be passed as a scalar Bytes value and then unserializing it on the client. Ideally we could skip the serialization step. However, the UserConfig type used in the Context class does not allow bytes values. We are not making use of the Context objects yet, but are considering it as a good way to store state information. Although one of the state objects is another nested dictionary.
I think this is a good change so long as it does not significantly interfere with other parts of the library. There might even be some other dictionary types in flwr.common.typing that could benefit from a recursive definition. Namely the Properties type and perhaps even the Metrics type. Although you might need to modify the aggregation function to recursively search the dictionary until it finds a scalar value to aggregate, but that would be worth the hassle in my opinion to allow more organized dictionary types
Describe step by step what files and adjustments are you planning to include.
For python, I believe the change is simple. Not sure if there would be any downstream effects. Here is an example of some changes to flwr.common.typing
Is there something else you want to add?
No response
The text was updated successfully, but these errors were encountered: