Refactor service interface for SHIP data

[randomdudebunchofnumbers]

Some of the methods in ServiceInterface return structures or pointer to structures which encapsulate the corresponding data. This is because the implementation just passes the various interfaces of ship-go to the service interface and the corresponding ship-go implementations are designed to be thread-safe. This current implementation violates the idea of having an interface specifically designed to separate the user level from the technical (EEBus) level. Furthermore, the encapsulation prohibits the data from being convertible into JSON or any other format in a generic manner.

I'd like to propose a data struct called ServiceItem with the following items:

type ServiceItem struct {
	Name                   string                       // shipapi.MdnsEntry
	Ski                    string                       // shipapi.MdnsEntry
	ShipIdPerMdns          string                       // field Identifier of shipapi.MdnsEntry
	Brand                  string                       // shipapi.MdnsEntry
	Type                   string                       // shipapi.MdnsEntry
	Model                  string                       // shipapi.MdnsEntry
	Serial                 string                       // shipapi.MdnsEntry
	Categories             []shipapi.DeviceCategoryType // shipapi.MdnsEntry
	Trusted                bool                         // shipapi.ServiceDetails
	ConnectionState        shipapi.ConnectionState
	ConnectionErrorMessage string
	RemoteDevice           bool // because the local device will also be listed
}

ServiceItem should be available via an API method and there should also be a corresponding callback in ServiceReaderInterface.

[DerAndereAndi]

Thanks for the suggestion!

As discussed: Another aspect is also how to register a remote device and have the stack verify that the SHIP ID is properly submitted in the SHIP handshake, instead of having the app to do it.

[randomdudebunchofnumbers]

See this post in Discussions