eclipse-ditto / ditto

Eclipse Ditto™: Digital Twin framework of Eclipse IoT - main repository
https://eclipse.dev/ditto/
Eclipse Public License 2.0
692 stars 225 forks source link

Enhance all Feature events with the feature definition #874

Closed thjaeckle closed 2 years ago

thjaeckle commented 4 years ago

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).

thjaeckle commented 4 years ago

Implementation suggestions:

jokraehe commented 4 years ago

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.

thjaeckle commented 4 years ago

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).

jokraehe commented 4 years ago

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"] }

thjaeckle commented 4 years ago

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"] 
  }
}
...
thjaeckle commented 2 years ago

Closing in favor of #710