Remove event list attribute support in the SDK
#35874
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Review changes with SemanticDiff. |
|
PR #35874: Size comparison from 20200ee to bf7bfb5 Full report (3 builds for cc32xx, stm32)
|
|
PR #35874: Size comparison from 20200ee to 4f2a7e5 Full report (88 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, nrfconnect, nxp, psoc6, qpg, stm32, telink, tizen)
|
tcarmelveilleux
approved these changes
Oct 2, 2024
tehampson
approved these changes
Oct 2, 2024
arkq
approved these changes
Oct 2, 2024
| @@ -806,20 +806,8 @@ Protocols::InteractionModel::Status CheckEventSupportStatus(const ConcreteEventP | |||
| return Status::UnsupportedCluster; | |||
| } | |||
|
|
|||
| #if CHIP_CONFIG_ENABLE_EVENTLIST_ATTRIBUTE | |||
There was a problem hiding this comment.
So the spec still has a non-D requirement for this check to work (which we have been violating, clearly).... Do we need a spec issue raised here to remove that? @tcarmelveilleux
There was a problem hiding this comment.
Could you add a link (or section number) for this here?
Code-wise I believe we did not have eventlist enabled in most cases anyway, so the change did not change behaviour (except some NXP examples). In this case probably spec should be updated to not use something marked as deprecated.
There was a problem hiding this comment.
The relevant spec section is "8.4.3.2. Incoming Read Request and Subscribe Request Action Processing" and it says:
- Each request path in the EventRequests field SHALL be processed as follows:
- If the path is a concrete path:
...
- Else if the path indicates a cluster event that is not supported, an EventStatusIB SHALL be generated with the UNSUPPORTED_EVENT Status Code.
This has nothing to do with EventList in the spec, so the spec is not "using something marked as deprecated". The spec just expects the server to know what events are "supported".
In terms of the SDK, we implemented that spec-required support check on top of EventList support, because the same data is needed for both. And yes, with EventList not enabled we had a divergence from the spec but the theoretical plan for fixing that was to enable EventList sometime.
So as I see it, there are basically three options here:
- Keep just not matching the spec here, as we have all along.
- Figure out how to implement this spec-required check.
- Change the spec to not do this check.
There was a problem hiding this comment.
I think 2 can be done. We can add AAI methods to list supported events, in addition to listing supported attributes. That would allow us to determine if an event is supported. I would argue that claiming it's supported when it will never be emitted is not a big deal for any client...
There was a problem hiding this comment.
Is there actual value for "2" ? Having event list metadata requires more code and metadata and the gain seems to be "disallow subscriptions for events that can never happen". But at the same time since events are emitted by the app, you do not even have assurance that events will ever be emitted. It seems we will default to apps just "select all possible events just in case".
There was a problem hiding this comment.
I would very much prefer that after 2 years we match spec to implementation here as this was promised at some point to also happen. The alternative seems to add overhead to people to define event metadata and require extra flash (even if minimal) to maintain logic for it.
yyzhong-g
pushed a commit
to yyzhong-g/connectedhomeip
that referenced
this pull request
Dec 12, 2024
* Remove event list attribute support * Restyle * Restyled by clang-format * Remove matter event list from defaults and from cmake builds --------- Co-authored-by: Restyled.io <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Specification marks it as deprecated (conformance
D) and we have not actually supported it in previous releases.For now remove all defines from implementing it. Client clusters still claim supported, so that may need further iteration.