RDK-55213: Add IPrivacy interface #410
Conversation
adrianM27
force-pushed
the
master_privacy
branch
from
3dfb280 to
a15cf9d
Compare
| // @event | ||
| struct EXTERNAL INotification : virtual public Core::IUnknown | ||
| { | ||
| enum |
There was a problem hiding this comment.
Add the destructor here. Like virtual ~INotification() override = default;
| ID = ID_PRIVACY_NOTIFICATION | ||
| }; | ||
|
|
||
| // @text onAllowACRCollectionChanged |
There was a problem hiding this comment.
I think, @sebaszm to confirm, but there is no need to use the @text to change the PascalCasing to camelCasing on JSONRPC. The Thunder framework (at least on R5.2) and further will except both for incoming and I think (again @sebaszm to confirm) send out the camelCase variant for events...
So if the intention is for this interface to be exposed on R5.2 or higher, the @text is no needed..
There was a problem hiding this comment.
That's correct, with small remark: acronyms will also be converted according to camelCase convention. So if uppercase acronyms (like "ACR" here) need to be kept uppercase then (a)text is still required in such cases.
There was a problem hiding this comment.
As a general remark, if I ook at the interface it looks to be in two minds.
Onvone hand you have a property for each field (all booleans) on the other hand you have an aggregated method to GetXXXX them all at once (a-symtrical, cause you can get all at once, but not set all at once) .
For me a clean/symetrical interface would rely on only one mind ;-) Or a struct to get and set them all (potentially a struct with Core::optionalType for setting only values you want during the Set. Or remove the GetXXXX and force the user to get the whole bunch of information through separate calls.
From a data consistency perspective (if properties might be related to each other) I would always opt to use a struct as this could in the imlementatio be made atomic, you always get a consistent snapshot of the flags, if you can block changes, while getting the current set. This is impossible with dedicated getters and setters.
This is a general remark I do not kow the intended usage but the fact that it is on two minds, I suggest to fix that, preferably, with the struct.
|
Thanks @pwielders for your time. Abandoning for now, since api will change completly |
No description provided.