Introducing ChannelProvidingConnection

[edwarnicke]

api.Connection is a very convenient interface for using
the RPC style binapi

Unfortunately, in order to Subscribe to Events like
interfaces.SwInterfaceEvent{} you have to have an api.Channel
against which you can call SubscribeNotification

Conveniently, core.Connection implements both api.Connection and
api.ChannelProvider.

Unfortunately, we have no type with which a function can indicate
it requires both of those interfaces.

ChannelProvidingConnection implements both api.ChannelProvider and
api.Connection allowing it to be used as a parameter to functions
which require an argument that implements both.

Signed-off-by: Ed Warnicke [email protected]

[edwarnicke]

I introduced this because I've found need to introduce it in multiple different places.

[ondrej-fabry]

This combined interface of Connection and ChannelProvider was purposefully omitted when the Connection and Stream were introduced.

The main reason behind this is that Channel should eventually be deprecated. So providing interface like this seems like adding extra work for users after they need to switch later and also possibly confusing users with the redundant ways to do things.

Rather, we should make ourselves more clear to the users about the planned intentions with the API. For this reason and also to open more broad discussion related to this I have created an issue where I started putting info related to this: Stream API & RPC services

The missing support for subscription/events is on point though, they are the missing piece in the Stream API. I have not mentioned it in the issue yet, but planning to update it with some info for this too.

Summary

I think adding this interface would make more work for us and the users in the long run compared the the work users currently need to do to achieve the same. One of the Go Proverbs is "A little copying is better than a little dependency."