Hi Johan, > Are you still working on this? Seems this discussion was forgotten or > just abandoned. I've been focused on something else, but nice to see you are still interested in. > Apparently it was never a requirement to be able to enable/disable this > an arbitrary amount of times during the watcher life time, and instead > just leave it disabled or enabled until the watcher gets unregistered? > > Also, do you think there will be UIs that will refuse to work if a > device does not support intermediate measurement or that any UI that is > interested in intermediate measurement will forgive devices that do not > support it and simply get on with working without it being enabled? If > the latter ilds true then why not make an API which allows requesting > > "register watcher and enable intermediate measurement if it's > supported". In such a case you wouldn't need a separate property and the > registration would succeed even if intermediate measurement isn't > supported. Thoughts? Well, I believe any app will always be interested in getting intermediate results if possible, but it would be nice to notify (property, signal) the app if it's not possible. Just to give a chance to handle user experience in nice way. It can take a while between start of measurements and the final results event. From the other hand, the app by default can assume there is no intermediate results ( (however API will not require that if there is no property)) and can handle this time properly. In case, when it starts receiving intermediate results it will start display it immediately. Thanks, /Waldek -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
