10:27 a.m.
Hi Daniel,
On 12/30/19 4:10 PM, Daniel Wagner wrote:
On 30.12.19 13:56, Jussi Laakkonen wrote:
> On 12/21/19 1:53 PM, Daniel Wagner wrote:
>> The missing concept in the Property API for changing multiple settings
>> at once leads to a bit strange things. Obvioulsy, it would be more
>> naturual to have single value set/get/clear/changed and the same thing
>> for multiple properties at once. Well, since this doesn't exist
>> neither for ConnMan nor for the freedesktop API let's go with this.
>>
>> Maybe we should bring this up at freedesktop and see what the
>> maintainers of the Property API think about it.
>>
>
> Having the methods for multiple properties would offer more
> flexibility, for the use of the method and in the underlying
> implementation. So yes, I'd agree that could be proposed in
> freedesktop as well.
>
> Specification [1] does, however, state, that there is a
> PropertiesChanged signal already in the D-Bus Properties interface
> (since version 0.14 in 2010) that can be used to indicate which
> properties were changed and which properties were invalidated (array
> of strings). So, the error reporting for the need of setting multiple
> properties at once (and clearing etc.) is already speficied. This may
> be good to implement in connman as well, when service.c would support
> setting multiple properties in one call.
The only thing we need to be careful, is not breaking existing users.
That means we still need to fire individual property changed signals.
Yes, individual property changed signals should be kept as is. But I did
get an idea from that approach for this multiple property setting. Would
it sound reasonable to send the PropertiesChanged as well when multiple
properties are set with one call, as the specification already supports
a list of invalidated properties?
So instead of packing them at the end of the error message that signal
could be used to indicate the client about the change. The D-Bus method
call return just would contain then a simple error, where invalid
property > permission denied, in case any of the property values could
not be changed.
I know, that would create duplicate content sent to clients and more
noise in D-Bus but it would be in line with the specs. Any thoughts?
> From the looks of it, PropertiesChanged is used only by the network
> manager compatiblity plugin (plugins/nmcompat.c) and gsupplicant.
> PropertiesChanged would not fit to all situations but to the ones
> where multiple properties are changed in any way.
IIRC, we needed it to emulate the NM interfaces. The 1.0 release of
ConnMan shipped without this API. In hindsight, it would have been
better to go with a PropertiesChanged...
Ah, some legacy content then. I'll nevermind that :)
Cheers,
Jussi