Re: [RFC] Health Thermometer Profile API

quoted

quoted

(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;

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.

Main problem would be having a "toothless" agent. Looks funny.