Feature/dynamic config alt #27
Conversation
…lementation of the core idea and notes on what would be next
| template<typename ConfigT> | ||
| ParameterEvenHandler(ConfigT* config, const std::string& key) | ||
| : key_(key), | ||
| meta_data_(config::internal::Visitor::getValues(*config)), //get meta data from config - we want this for field information etc... TODO: need to do checks |
There was a problem hiding this comment.
Note: The info is generally not static, i.e. for virtual and array/map configs the config layout can change. This is what the getInfo function is meant to return in our demo.
|
|
||
| std::cout << "old yaml " << old_yaml << std::endl; | ||
|
|
||
| if (config::internal::isEqual(old_yaml, new_yaml)) { |
There was a problem hiding this comment.
Note: It is well possible that the new_yaml is different but the resulting config is the same (e.g. if params are invalid or unrelated), so probabyl should check after parsing.
|
|
||
| //TODO: alert which field has changed!? | ||
|
|
||
| // std::lock_guard<std::mutex> lock(mutex_); |
There was a problem hiding this comment.
Note: Since Dynamic configs will always be set from outside these interfaces must be thread-safe.
|
|
||
| public: | ||
| template<typename ConfigT> | ||
| ParameterEvenHandler(ConfigT* config, const std::string& key) |
There was a problem hiding this comment.
In our demo all dynamic configs are registered with a unique string key (or name/id), is this the same idea?
| } | ||
|
|
||
| template<typename ConfigT> | ||
| bool attemptUpdate(const ConfigT& config) { |
There was a problem hiding this comment.
There's probably a philosophical question how much the clients should have to know about types. In general for a C++ client it could be nice to provide a typed interface. Would it make most sense to directly template the client/interface?
On the other, can also be nice to just accept any YAML (so conversions between types and non-C++ clients work well).
| auto interface = std::make_shared<ManualInterface>(); | ||
| DynamicReconfigureServer::registerInterface(interface); | ||
|
|
||
| //I am unclear about this key. Does it need to be namespaced according to anything else in the system? |
There was a problem hiding this comment.
the key would be a an identifier that is unique to each server (in the case of a ROS node e.g. resolved to the node). The a global identifier is required so that outside clients can send their updates to the right address. If you run our ROS example you could e.g. have several ROS nodes with dynamic config servers, and in the UI you can select the server + the config for each server to target. For other applications the end user would be responsible to namespace or otherwise disambiguate configs correctly (e.g. by having an ID counter in objects using dynamic configs).
|
|
||
| //I am unclear about this key. Does it need to be namespaced according to anything else in the system? | ||
| //Ideally not as its just some key that refers to an INSTANCE of a config and not the Config type (like config::name()) | ||
| //some bookeeping could be done here. |
There was a problem hiding this comment.
Exactly, this is the idea!
| interface->set(new_config, "my_config"); | ||
|
|
||
| new_config.f = 10.0; | ||
| interface->set(new_config, "my_config"); |
There was a problem hiding this comment.
If I understand correctly this interface directly binds to a config in the same process? Wouldn't it be easier for this use case to design the system such that the actual config structs are available e.g. in a singleton and modify them directly? That would make a lot of the parsing easier?
| * The interface gets a new function that allows sub-updating e.g. Interface::setField(T, namespace) | ||
| * e.g interface->setField(10.1, "my_config/f") | ||
| * | ||
| * since we have access to my_config and we know how to access the YAML field 'f' associated with that config we can just update the field in the yaml. |
There was a problem hiding this comment.
I don't think that will quite work since constructing the SimpleConfig will set the other fields to default, but calling update on the existing config (or a copy) will do what you want.
| * Of course you can update the whole config by using the "base"/(root?) namespace, which in this example would be "my_config". This is also type checked as we store | ||
| * the type of SimpleConfig (as is currently implemented)/ | ||
| * | ||
| * This would get around the client side needing to know how to build the WHOLE Config type, you just need to know the namespace and the type of the field (which I guess you |
There was a problem hiding this comment.
This was the idea behind the YAML-based interface, i.e. the client won't have to know anything about the config, it will send the updates and the local config will know what to do with it (and ideally send a response in the final version)
If one knows the type of-course it could be nice to provide a templated client that can do some checks locally before sending to the config if this is what you're referring to?
No description provided.