Closed thjaeckle closed 2 years ago
Implementation suggestions:
WithFeatureDefinition
which all FeatureEvents implementdefinition
field to all FeatureEvents (also add it to the serialized JSON)definition
would have to find its place e.g. in the headers, e.g.:
{
"topic": "com.acme/xdk_53/things/twin/events/modified",
"headers": {
"feature-definition": [
"org.eclipse.vorto:Foobar:1.0.0"
]
},
"path": "/features/accelerometer/properties/x",
"value": 42,
"revision": 1
}
{
"topic": "com.acme/xdk_53/things/twin/events/modified",
"path": "/features/accelerometer/properties/x",
"value": 42,
"definition": [
"org.eclipse.vorto:Foobar:1.0.0"
],
"revision": 1
}
I think the top-level definition
in ditto-protocol would make sense, because we also could support the definition of a thing with this approach. We could name the interface WithDefinition
then we can reuse it for thing events.
Ok, but then the definition depends on the changed "path"
which could be confusing.
We could also add toplevel "definition"
and optionally "feature-definition"
(when a feature was affected).
Yes, you are right. The top-level definition is not unambiguous for feature related events. Maybe we could add something like
"definitions": { "thing": ["org.eclipse.vorto:Foobar:1.0.0"], "feature": ["org.eclipse.vorto:Baz:1.0.0"] }
that leads me to: what if an event contained updates for several features - then the JSON should probably look like:
...
"definitions": {
"thing": "org.eclipse.vorto:Foobar:1.0.0",
"features": {
"featureA": ["org.eclipse.vorto:Baz:1.0.0"],
"featureB": ["org.eclipse.vorto:BazBaz:1.0.0"]
}
}
...
Closing in favor of #710
We could simply add the Feature "definition" to all Feature events. That way, the definition would not have to be "enriched" (e.g. as also requested in issue #710) but would always be available (similar to the Feature's ID).
We could also add a Placeholder
{{ feature:definition }}
in order to e.g. add the definition in a header mapping (e.g. putting the definition as HTTP header for HTTP push connections).