New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove the need of a provider for capability dependency in another provider #38
Conversation
Addition: This setting is also overriding the defaults. |
It is supposed to use the default in that case so this is a bug. However, since the robot developer is providing all of the provider files it should not be a problem to be specific, in fact I would encourage being specific except for were you explicitly need the flexibility. I'll get this fixed. |
In your above case I wouldn't think that you intend the |
Upgraded to a pull request. |
Remove the need of a provider for capability dependency in another provider
No, I actually would like to allow any provider. In this specific example, the provider could be a kobuki-, create- or roomba_differential_mobile_base provider. Isn't that the idea of the caps/interfaces? |
That's true. But in this example the developer focuses on implementing the provider of the TurtleBotBringup capability. It might be the same person, who implements the provider for the DifferentialMobileBase, but this should be a requirement. Without this requirement, we would be able to compose complex sets of capabilities using existing capabilities + providers (if they fit) as building blocks. |
Yes it is, I wasn't aware you were trying to achieve that, this is one of those cases where you explicitly need the flexibility. There are two cases where you would use a provider which depends on another interface:
In the first case you want to not specify a provider in the dependency because you don't care what provider is used as long as it implements the interface you depend on. In the second case you probably do care which provider is being used because you don't actually need anything declared in the interface you depend on, you just need the things which are side effects of running its provider. I don't really understand the case you have laid out above. Without understanding how you have laid out of everything it would be hard for me to understand it, but I would have made the provider for DifferentialMobileBase depend on TurtlebotBringup as a necessity (the implementation lives there), not the other way around. In fact without using TurtlebotBringup as a sort of phony implementation capability I don't understand why you need it anyways? What app will depend on TurtlebotBringup? What functionality does it provide, which is not already described in DifferentialMobileBase or some other interfaces? |
That is what I am doing.
Agreeing.
This picture might better explain this than my words. I broke the So, Does this clarify my need for the optional provider parameter/specification? |
Currently, when specifying a capability dependency for a provider, a provider needs to be specified for that dependency. I'd like to make this optional.
I.e. I'd like to do this:
But currently, I need to do this:
Otherwise I get an error, when this provider is started:
IMO, setting (default) providers is the job of the capability server launcher or the service client.