Hi Mika, <snip>
> > 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. > Of course, and patches are always welcome. <snip> >> 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 disagree. I think upstream will be notified and we will improve the situation as we progress. But I do agree it might be too late for that particular product. Of course that is the case with all software. <snip> >> 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 >> D-Bus, similar >> 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. > One of the biggest principles in oFono is not to perform premature optimization. Sure there is a potential issue, but nobody knows whether it will actually manifest itself outside of malicious code (which we tell to bugger off) or what the most common manifestation pattern will be. If / once we know for sure this is a problem, then we can solve it properly. So far this approach has been working very nicely for us. There are countless occasions where taking the wait-and-see approach and gathering more information allowed us to devise a much better solution than we would have originally. So the general rule is: Do the simplest thing that is likely to work. If it doesn't work, improve it. > Br, > > MikaL Regards, -Denis _______________________________________________ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
