On 20 March 2017 at 15:53, Denis Kenzior <denkenz(a)gmail.com> wrote:
> Not sure, I thought it would be better to guarantee the ordering
> the dbus socket generally for all messages and not have to worry if
> the issue may possibly come back in the future. I think it should
If you're worried about every possibility that you're being this heavy
handed, it might be simpler to just get rid of the coalescing code and
simply always emit the property changed signal right away. We're not saving
much on average by having it.
> affect at least method returns, signals and errors, if we want to do
> it. Method calls I'm not sure because services don't make any except
> to agents, but it may be worth doing for the agent calls.
errors should not affect properties.
I don't see why not, a Connect error will cause State to change for
example, could also affect some KnownNetwork properties, but there
will be some more obvious cases.
Your signal + InterfacesAdded example is valid, though probably never occurs
in practice. I can't think of any other situation where an in-order signal
reception was useful.
In all cases it can be worked around by clients like in the Scan case.
We can fix it on the iwd side just for this one case but I think
instead we should have a policy that tells clients if they can rely on
the order of the signals or not. If not then the test utilities
should deal with this.
Method calls I think we can ignore completely.
>> Also, this causes (potentially lots) of getter calls to be made. Would
>> not be better (and safer) to only send the properties for the object
>> is generating the method return?
> Again if we do that there will be some situations where the clients
> will have to work around issues. If the getter calls are an issue we
> can probably move the other messages to idle callbacks too, relatively
I detect hand-waving :) Can you describe specific situations where this is
The Scanning case is one but really it's same as other situations
related to State and other properties, where the client code
(including agent methods) need to take some decision based on the
Fixing it just for the Scanning case probably costs us about a line
more or the same amount code as actually fixing it in general.
Dropping the coalescing code would simplify the code even more though.