Add strong data typing for inputs and output to commands as part of BIRTH or METADATA

[wes-johnson]

This came from a list of suggestions in #432.

[wes-johnson]

Not sure exactly what this means. It will not be included in Sparkplug 4.0.0 unless we get some clarification.

[matthewGEA]

@wes-johnson I believe the intention is to enable commands to have definitions that include the number of parameters, name of parameters, and datatype for each parameter. Also, the response would also have definition (structure, datatype, etc). These command structures would be advertised through some mechanism, similar to the BIRTH certificate.

[RickBullotta]

Hi, Wes. Pretty much as Matthew described: Commands should have strongly typed inputs and outputs.

[jbrzozoski]

From my point of view, it's non-compliant to send NCMD/DCMD payloads to metrics that weren't defined as part of a NBIRTH/DBIRTH. I suppose there's nothing preventing it from being done or having an edge node respond to one though.

But, inversely, on the edge nodes I've worked on I've always reported all metrics that accept commands (and their data types) in the BIRTH messages which achieves what this issue wants. Even if the command metrics never report any data in BIRTH or DATA payloads, I just send a value of NULL or 0 or empty string in the BIRTH depending on datatype.

Does that make sense, or am I completely misunderstanding what this issue was requesting?

[RickBullotta]

Commands should not need to have any correlation to metrics. A command should be a "function", which may or may not have a return value.

[martinscheffler]

I just stumbled onto this topic while looking at something related: When looking at a birth message, how can I distinguish metrics from commands? I would like to write a UI that lets the user send all commands defined in the birth message, but there is no way to check if a payload metric is a command, except by looking at the name of the metric.

[RickBullotta]

To clarify this request, simply think of other API metadata/documentation techniques such as Swagger and others. The inputs to a command should clearly enumerate the data type(s) and/or data structure(s) that represent any inputs that will be sent for a specific command, and commands should be expanded to be bi-directional, allowing a return value from a CMD as part of a request/response pattern. In that case, the response data type(s) and data structure(s) should also be declared in any metadata provided by edge nodes. The format for these inputs and outputs would naturally use the same syntax as Sparkplug metrics. And of course, if a command does not accept any inputs or outputs, that is perfectly acceptable. But a command that accepts input must define the payload and a response payload of any.