> The fundamental problem here is that there is only a single
CACHED flag for multiple properties, which may be modified
individually. So, either you get extra signals or you get too
few. I checked the CACHED flag here because otherwise the
following might happen:
Yes, I know. But this problem is present in every single atom. oFono
does not guarantee that every attribute is signaled when the atom is
So I gathered. To me this looks like a wider issue, though. InProgress errors are returned
in many other contexts as well, and they are not that well documented in the API
documentation. All this makes it a bit painful to write a robust oFono client. Probably
this could be at least partially rectified by improving the documentation.
> 1. client tries to GetProperties() and gets the "Operation
already in progress" error.
> 2. client waits for PropertyChanged signal to get the
> 3. signal never comes because the default value happens to
match the one returned by the driver and the signal is suppressed
In general I think that for interfaces where this can happen, the
likelihood is very low that it actually will in the real world.
Perhaps so. The network and SIM interfaces, which are most likely to be bombared by
multiple UI components, seem to be doing the right thing at least.
Do note that I have had the same argument with myself off and
on for the
past two years. So far this was never raised as an issue.
If this ever
becomes a problem, we can fix it properly using an appropriate idiom.
If this becomes a problem, it won't necessarily be visible to upstream. More likely
this will be noticed in product maturization phase, and the fixes made to a product
specific stable branches might never trickle back to upstream.
> I do agree that sending extra signals is bad but I think
that not sending a signal is even worse. If the client cannot
rely on getting a PropertyChanged signal after a busy error,
all it can do is resort to polling. I.e., every client has to
implement a polling pattern for GetProperties:
> while (GetProperties() == BUSY)
> Having a separate CACHED flag for each value would solve
this optimally. Failing that, I don't think a few extra
signals is so bad. Forcing clients to poll is just ugly.
Honestly, if you expect multiple applications to battle over the
FastDormancy property, then it should be modeled differently. Perhaps
with application registration and lifetime tracking over
to how agents work.
Hardly that, FastDormancy is unlikely to be a problem. I was merely curious whether there
is a general design rule underneath, or if these things are decided on a case by case
basis. Based on your comments and looking at the code, I guess it's more case by case.
I just feel uneasy about an API that returns transient errors by design, on the (even if
informed) assumption that it will probably be ok. I also dislike the fact that a generic
InProgress error pretty much forces a client to just retry each operation until it
succeeds. If there are problems like this, they are most likely discovered only in the
product maturization phase and then it's generally too late to fix the upstream. Too
late for that particular product, that is.