-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define a IM/DM decoupling interface for interaction model engine to interact with the data model bits #32914
Conversation
…er validate that we get events emitted
- Remove unneeded includes from this header - add dependency to core (due to TLV)
PR #32914: Size comparison from c4699cf to e6cdc3e Increases (3 builds for cc32xx, mbed)
Decreases (1 build for stm32)
Full report (4 builds for cc32xx, mbed, stm32)
|
PR #32914: Size comparison from c4699cf to e4b0010 Increases above 0.2%:
Increases (46 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, mbed, nrfconnect, psoc6, telink)
Decreases (44 builds for bl602, bl702, bl702l, cc13x4_26x4, efr32, linux, nrfconnect, nxp, psoc6, qpg, stm32, telink)
Full report (71 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, mbed, nrfconnect, nxp, psoc6, qpg, stm32, telink)
|
Co-authored-by: Terence Hampson <[email protected]>
Co-authored-by: Terence Hampson <[email protected]>
Co-authored-by: Terence Hampson <[email protected]>
Co-authored-by: Terence Hampson <[email protected]>
PR #32914: Size comparison from c4699cf to 5f76b9c Increases above 0.2%:
Increases (46 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, mbed, nrfconnect, psoc6, telink)
Decreases (44 builds for bl602, bl702, bl702l, cc13x4_26x4, efr32, linux, nrfconnect, nxp, psoc6, qpg, stm32, telink)
Full report (71 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, mbed, nrfconnect, nxp, psoc6, qpg, stm32, telink)
|
PR #32914: Size comparison from c4699cf to d134fab Increases above 0.2%:
Increases (44 builds for bl602, bl702, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, mbed, nrfconnect, psoc6, telink)
Decreases (54 builds for bl602, bl702, bl702l, cc13x4_26x4, efr32, linux, nrfconnect, nxp, psoc6, qpg, stm32, telink)
Full report (71 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, mbed, nrfconnect, nxp, psoc6, qpg, stm32, telink)
|
namespace InteractionModel { | ||
|
||
/// Data provided to data models in order to interface with the interaction model environment. | ||
struct InteractionModelActions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here's a problem: "Action" in the context of the interaction model has a specific meaning, and this struct has absolutely nothing to do with that meaning.
I can't tell by looking at this struct name, or the struct definition, what is supposed to go into here and why it has, say, Events but not Attributes or Commands. And I have no idea what Paths is supposed to be. If it's "things you can do with paths", that seems like the wrong level of abstraction to me.
This is really "InteractionModelAPIs" or something. But then broken down into separate structs for separate types of APIs... (more on this below).
Realistically, this should perhaps have been called chip::app::InteractionModel
(as a class, not a namespace), but if we are using that name for the namespace.... chip::app::InteractionModel::Instance
? chip::app::InteractionModel::Callbacks
? Something else? I am struggling to find a sensible name here.
namespace app { | ||
namespace InteractionModel { | ||
|
||
/// Handles path attributes for interaction models. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are "path attributes"?
Was this supposed to be "attribute paths"? But if so, the generic "Paths" naming is really odd.
This starts implementing based on the proposal in https://hackmd.io/@6NmxK83qTm2u-ya_60bJEg/S1swIFbxR
There is little implementation, mostly headers and virtual interface declarations.
The intent is to have changes reasonably small for review purposes rather than attempting one large PR at some future point in time. The downside on this is that we may find some things that don't map well and may need moving around as this is developed (especially command handling with batch support seems to potentially be complex).
Changes
app/interaction-model
(because data-model was taken)