MessageHandler interface enhancements

[stoyan-zoubev]

This is the current version of the MessageHandler interface:

type MessageHandler interface {
	Init(settings *config.AzureSettings, connSettings *config.AzureConnectionSettings) error
	HandleMessage(message *message.Message) ([]*message.Message, error)
	Name() string
	Topics() []string
}

First, it is used in both directions - cloud-to-device (command) messages and device-to-cloud (telemetry) messages. However, not all methods apply to both directions, e.g. communication between the device and Azure IoT Hub goes on with strictly-defined topics, so in case of cloud-to-device messaging MessageHandler.Topics() is never used. It is only used in case of device-to-cloud messages in order to specify local topics for subscriptions. It is better to have a clear separation between command and telemetry handler interfaces.

Second, the handler registries required handlers to be instantiates empty and Init method to receive settings. If pluggability is improved with [#17 Improve message handler pluggability] then this no longer be needed and handler settings can be passed to handler constructor methods. Init method may remain and receive only data that is not yet known upon handler creation - AzureConnectionSettings, or even better a subset of this structure with only useful data for message handlers - e.g. device connection info like device ID, Azure IoT hub name, hostname.

Additionally, on the Topics method - the underlying watermill library method uses type string, not []string. It is preferred to align the interface with the library by modifying the return type and avoid unnecessary conversions.

Proposal:

// MessageHandler represents the internal interface for implementing a message handler.
type messageHandler interface {
	Init(deviceInfo *config.DeviceInfo) error
	HandleMessage(message *message.Message) ([]*message.Message, error)
	Name() string
}

// CommandHandler represents the internal interface for implementing handlers for cloud-to-device messages from Azure IoT Hub.
type CommandHandler interface {
	messageHandler
}

// TelemetryHandler represents the internal interface for implementing handlers for device-to-cloud messages for Azure IoT Hub.
type TelemetryHandler interface {
	messageHandler
	Topic() string
}

where config.DeviceInfo is the device connection data in subset structure in config package:

// DeviceInfo contains the device related info.
type DeviceInfo struct {
	HubName  string
	DeviceID string
}

// AzureConnectionSettings contains the configuration data for establishing connection to the Azure IoT Hub.
type AzureConnectionSettings struct {
	*DeviceInfo

	DeviceCert    string
	DeviceKey     string
	TokenValidity time.Duration

	*SharedAccessKey
}

Also, the handlers.go source file may be moved directly into routing/messages/handlers directory, package handlers and get rid of common package.

[e-grigorov]

• The handlers should not be Watermill specific i.e. no type, doc etc. dependencies
• DeviceInfo.HostName - the naming has to be improved, the host name doesn't seem to be device info, all names have to be revised

[stoyan-zoubev]

I agree with you, @e-grigorov. But I also have some comments:

• Making the handlers not to be Watermill specific means defining a struct to represent the message in order to replace watermill's Message struct. I am OK with this but let's do it step by step. Just keep this issue with the proposed changes in the description in order to make the handler interfaces more usable, with relatively less number of changes. And in the future, we may go with removing the watermill dependency in the interface (if it is really worthy).
• I will try to come up with a better name for the given structure, as a replacement for DeviceInfo. What about CloudConnectionInfo? Do you think it is better, shall I update the issue description? Any suggestions from your side are welcome :)