Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Simplify and split HonoClient for applications versus protocol adapters

See original GitHub issue

Originating from a discussion on the dev mailing list, I think we should split the HonoClient to at least two different use cases:

what typical applications need
- telemetry and event consumers
- command senders
what (custom) protocol adapters need
- telemetry and event senders
- tenant, credentials and registration clients

I am sure this needs some discussion - I can imagine that the tenant, credentials and registration clients might be desirable to have available outside a protocol adapter as well, so that we would have three different clients. A use case for that could be a device registry client application IMHO.

The point of this issue is to come to a more focussed HonoClient, so that an application developer should not have to ask a question like “why do I have a telemetry sender available, but I cannot use it since I can only consume telemetry messages?”. The same question could be asked for the tenant, credentials and registration clients, for which the remote APIs are usually not accessible for applications.

After having discussed this issue, we can rewrite it to describe what we want to achieve in the future with HonoClient (and possibly split it up).

Remark: for Command and Control we already made a small step into this direction : the CommandConnection is an extension of HonoClient and thus does not provide it’s methods to applications.