enbility / spine-go Goto Github PK

If a feature allows write, but does not announce partial, the remote device should not send partial writes. Hence the partial should be declined with an error in the ack return message

When a write message was accepted, and the data successfully merged, a notify of the updated data set should be sent to all subscribers.

This data model is quite different to the other models using listdescription and listdata. Right now the stack will trigger a full read incoming on partial data for this model.

What is needed:

• partial and delete merge support

• If a duration is provided for a TimePeriodType EndTime value, and no StartTime is provided in a write message, the endTime should be converted to an absolute timestamp
• A helper method should provide the current duration being left
• On serialization the current remaining duration should be used
• On every subsequent write, the same process should be repeated.

An application should be able to allow or deny write operations to a local server feature.

One example is that LoadControlLimits are set which are outside of the allowed and assigned ElectricalConnectionPermittedValueSetData. As these are loose dependencies defined in use cases, it is nothing the stack shall or can do automatically.

Current situation:

• Right now one can only subscribe to everything
• Every subscriber will be informed about an event on an independent thread

Ideas to improve this:

• Option to un-/subscribe to specific/set of EventType
• Option to provide a channel for receiving events
• Option to provide a callback functions to be invoked for events

More ideas?

Right now a local server feature only allows setting the complete data set. This will then always trigger a full notify to all remote client features, even though data they are interested in might not have been changed.

To improve this, an UpdateData feature should be introduced, that supports deletion of (partial) data and updating new data. This should then trigger a partial notify for this data only and be merged locally.

This should be possible to be implemented with the same/similar way a remote partial update is processed.

I think if it is fine, to expose an update the requires the API user to actively think about deletions, partial updates in the way SPINE does it. Then the stack wouldn't have to do any magic but the API user has to really know what they are doing.

Instead of manually checking every incoming write messages, they are handled fully automatically. To make sure data is rejected from being written from a remote client, the appropriate field items indicating if data is allowed to be written, need to be set.

E.g for LoadContrlLimitListDataType the field IsLimitChangeable needs to be set to false

Functions in FeatureLocalImpl that request, notifiy or write data to a remote address should check, if the remoteEntity does support the requested operation on the function

Instead of creating the DetailedDiscvovery data structures in device, entity, features and operations using Information(), use the SPINE model data structure instead and therefor remove custom code for handling this.

Noticed during evcc-io/evcc#13998 that this package now relies on github.com/hashicorp/golang-lru/v2 which is under MPL license. In general, projects like spf13/viper are trying to move away from depending on hashicorp due to their licensing changes. I'm no expert but wondering if MPL is compatible with MIT?

Multiple bindings are allowed per spec (in fact they are not prohibited).

The flow then should be:

• The first client that writes on a specialization (combination of descriptions resulting in an ID) will have the sole write access to that ID, others will be denied, until the binding is removed
• This requires to store a current active write access list per ...ListDataType key combinations

The current behaviour is that only one binding is allowed.

If the remote device sends a notify with a partial dataset for a data structure that does not support partials yet, automatically send a read to receive to complete update date dataset.

SPINE covers way more data structures and constants than all use cases currently use. But right now everything is always included. So the task is to check out if the library size could be made smaller depending on the used usecases.

• Add option to trigger read requests with a filter
• Check wether the remote device supports partial read requests, otherwise trigger a full read

• Announce specific functions to support partial reads
• Implement to reply with the requested filter

For the following list types namespaces, the update criteria is currently unclear:

• DirectControlActivityListDataType
• NetworkManagement...
• NodeManagementDestinationListDataType
• SensingDataType
• UseCaseInformationListDataType
• SpecificationVersionListDataType