Hi, On Wed, Jun 22, 2011 at 6:50 AM, Elvis Pfutzenreuter <epx@xxxxxxxxxxx> wrote: >>>> (cut) >>> >>> True, I did not remember that those were properties. They would have >>> to go, otherwise it is too easy for an app to "break" another, by >>> disabling notifications. >>> >>> A pair of Enable/DisableIntermediate methods taking an agent as >>> parameter would be more adequate. >>> >>> IMHO there would not be a need of such >>> methods for final measure, because the final measurement (which is >>> the only one guaranteed to be precise) is the final objective, there >>> is no point in registering an agent and not wanting a final measurement. >>> >> >> They werent in this RFC. I only see a problem now, for example if an >> agent wants to get only a single *final* measure without setting an >> interval and after a while the same agents decides that it wants to >> get a new single measure without setting an interval for periodic >> measurements. I don't see how it could do this with current API (where >> get final measure methods are not present). > > For that, having temperature as one of the properties would be great > (allowing apps unable/unwilling to set up an agent to read it). > > Or setting a convention that, if you register an agent, a GATT read is > fired and you get a measurement right after. (It seems that you said > something in that direction below.) Disvantage is that registering > and unregistering agents just to get 1 measurement would cycle > GATT indications needlessly. > >> We could think that an agent is only registered during the time it is >> interested in being notified about final measures, after that, it >> should unregister itself from the service. In that scenario we can set >> notify property for final measures each time an agent is registered >> (if not periodic interval is already set). > > In terms of minimizing energy consumption and API methods, the 'best' > would be: > > a) intermediate and final temperatures being properties (intermediate > property is there only if thermometer supports it). > > b) There are GATT reads on them when some app reads the property; > [MT] Final temperature can only be indicated and intermediate temperature can only be notified. Client can't read them from server, according to the Thermometer profile spec. > c) those properties generate PropertyChanged signals only when > notifications are enabled for one or another, or there was a GATT read; > > d) applications signal interest in notifications by registering > an agent (or by some other way). Registering an agent automatically > means interest in final temp notifications, an additional method > enables/disables interest in intermediate temp notifications. > [MT] Once indication or notification is enabled, client has to be ready to receive notification or indication as soon as the physical link is established with the temperature sensor. > Main problem would be having a "toothless" agent. Looks funny. > -- > 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 > -- 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
