Skip to content
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

[Feature] DoorLockServer: Add source attribute for lock/unlock commands #25105

Open
deveritec-rosc opened this issue Feb 16, 2023 · 5 comments
Open
Labels
door lock Issues in the Door Lock cluster or example apps

Comments

@deveritec-rosc
Copy link
Contributor

Feature description

In the current implementation of the door-lock server, emberAfPluginDoorLockOnDoorLockCommand and emberAfPluginDoorLockOnDoorUnlockCommand do not expose the source of the lock/unlock command.

In the example (and a current PoC I am working on), this information would be beneficial.

From the current interface, I see no easy way to add this functionality, since it would either

  • break the function by adding the source argument at the correct place (before the return parameter), or
  • breaks the used style that the out-parameter is placed last

Platform

all

Platform Version(s)

No response

Anything else?

No response

@bzbarsky-apple bzbarsky-apple added the door lock Issues in the Door Lock cluster or example apps label Feb 16, 2023
@bzbarsky-apple
Copy link
Contributor

bzbarsky-apple commented Feb 16, 2023

@deveritec-rosc I'm not sure why "break the function" is just for the first option. Both options would "break" the function in the sense that it would need to be changed in existing API consumers.

I think fundamentally we have two options: we can either change the signature and all API consumers have to notice and update (probably any basic testing would catch this need), or we add a second function we call and then API consumers that want the extra info implement that, not the existing one.

@deveritec-rosc
Copy link
Contributor Author

Yeah, I get it. I was just thinking that adding an optional paramter to the header may solve this, but the function would be recognized as an overloaded one.

From my point of view, changing the whole function signature and hoping that basic testing (or compile time errors) may catch this appears to be the "cleaner" solution. Adding a second function introduces the need for some static checks to avoid unintended behavior, but I would be open for that.

@bzbarsky-apple
Copy link
Contributor

@deveritec-rosc Compile time errors will not catch this, since this function is defined as a weak symbol. But yes, basic testing should.

@stale
Copy link

stale bot commented Oct 15, 2023

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

@stale stale bot added the stale Stale issue or PR label Oct 15, 2023
@bzbarsky-apple
Copy link
Contributor

@deveritec-rosc What "source" information were you looking for? The current emberAfPluginDoorLockOnDoorLockCommand and emberAfPluginDoorLockOnDoorUnlockCommand signatures seem to include a fabric index and node ID (when those are available).

@stale stale bot removed the stale Stale issue or PR label Oct 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
door lock Issues in the Door Lock cluster or example apps
Projects
None yet
Development

No branches or pull requests

2 participants