-
Notifications
You must be signed in to change notification settings - Fork 17
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
[QUESTION] How to register a third party service with Chariott #117
Comments
Hi Kai, Thanks for your question! I am going to answer it in two parts, first the general case and then specific to MQTT brokering. Registering a third party service with Chariott: You are correct that a Provider interface needs to be implemented for the service and register itself with Chariott. Currently the way Chariott implements discover is by directly calling the provider of the requested service to get the necessary endpoint information. Thus, a provider conforming to provider.proto is needed. MQTT broker service with Chariott: There is currently a Pub Sub provider service being implemented right now that should be posted under Chariott soon that will integrate with Chariott as a service and provide pub sub functionality to the vehicle with dynamic topic management. The model being used is a Bring your own broker approach which will allow for different messaging brokers to be used with minimal code changes. It will handle the Chariott registration. The current PoC is being developed with an MQTT broker. Let us know if you have any further questions! |
Thanks for the answer(s). I wonder, though, if you have plans to change the current requirement of having to implement provider.proto just for registering a URI. FMPOV this poses a very strong dependency on Chariott which will make it very hard to integrate third party services as it would require implementing a service proxy, or am I mistaken? The fact that you are implementing a standard proxy for MQTT brokers is appreciated but FMPOV the overall service registration model should be less intrusive. |
Another point I realized while implementing provider.proto was that there is a lot of boiler plate code that is required to actually implement the interface. The examples folder seems to contain some/most of this but FMPOV it would be desirable to have a separate crate that I can depend on that contains all of this code instead of having to copy the code into my service implementation. WDYT? |
You bring up some good suggestions. On the point of service registration being less intrusive, we are considering changing how discover works so that a provider can give the information discover needs at the time of registration. This is part of a bigger redesign effort that has just started. On your point about a crate, I can see the value of having a crate that handles some of the boilerplate code. However, in the examples, we want to explicitly show all the steps needed to successfully use Chariott as a provider without hiding any of the code behind a crate/library if possible. This is partially due to the fact that not everyone interacting with Chariott will use Rustlang, and it is useful to have the full steps laid out for interacting with Chariott in the example. This should allow anyone who has the desire/need to create a library in the language of their choice. |
This sounds like a great step into the right direction 👍 |
Hi Kai, Thank you for your question and the great discussion. We have created issues #134 and #139 to address both the simplification of service discovery as well as the pub-sub initiative, for which the work is currently in progress. I will close this thread for now, but please feel free to comment on those issues or open a new one if you have further questions or suggestions. |
Hi,
I was wondering if there is any way to register a third party service like for example an MQTT broker with Chariott so that clients could use Chariott's discover intent to determine the MQTT broker's endpoint address and then connect to the broker directly?
My understanding so far is that a service needs to implement the Provider interface for this purpose. However, that seems to be a lot of effort for just exposing the MQTT broker's URI ...
The text was updated successfully, but these errors were encountered: