Return-Path: MIME-Version: 1.0 In-Reply-To: <7B7AE0E9-F6A0-4EBD-9FEA-44DD9C7996D0@signove.com> References: <1308661408-8364-1-git-send-email-sancane@gmail.com> <544C7016-5346-4C99-AEA9-C91AA84E3A42@signove.com> <7B7AE0E9-F6A0-4EBD-9FEA-44DD9C7996D0@signove.com> Date: Wed, 22 Jun 2011 14:44:42 -0700 Message-ID: Subject: Re: [RFC] Health Thermometer Profile API From: mike tsai To: Elvis Pfutzenreuter Cc: Santiago Carot , linux-bluetooth@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-bluetooth-owner@vger.kernel.org List-ID: Hi, On Wed, Jun 22, 2011 at 6:50 AM, Elvis Pfutzenreuter 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@vger.kernel.org > More majordomo info at ?http://vger.kernel.org/majordomo-info.html >