Skip to content
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

Closed
sophokles73 opened this issue Apr 17, 2023 · 6 comments
Closed

[QUESTION] How to register a third party service with Chariott #117

sophokles73 opened this issue Apr 17, 2023 · 6 comments

Comments

@sophokles73
Copy link

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 ...

@devkelley
Copy link
Contributor

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!

@sophokles73
Copy link
Author

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.

@sophokles73
Copy link
Author

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?

@devkelley
Copy link
Contributor

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.

@sophokles73
Copy link
Author

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.

This sounds like a great step into the right direction 👍

@ladatz
Copy link
Contributor

ladatz commented Jun 14, 2023

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.

@ladatz ladatz closed this as completed Jun 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants