Hi Johan, On Tue, Aug 28, 2012 at 2:10 PM, Johan Hedberg <johan.hedberg@xxxxxxxxx> wrote: >> The registered "watcher" object will have different interface >> depending on the profile. The application which will call >> RegisterWatcher() needs to check that the device supports the expected >> GATT service (e.g. by checking the "UUIDs" property of that device >> object) before using the org.bluez.HeartRate interface, therefore >> IMHO it makes sense to have RegisterWatcher() on the device object >> path. > > I'm not quite following. You'd still have per-profile interfaces on the > adapter path. What I meant, is that, before using RegisterWatcher(), you need to check the "UUIDs" property on the device path. So you still need to either enumerate all device objects and read their "UUIDs" property, or monitor the "PropertiesChanged" signal (once the new Property API is upstream). So IMHO ff you need to access the device object, there is no gain in moving the method to adapter object. >> Unless you are proposing a generic Watcher API that could somehow be >> shared by all profiles (including a single shared interface for the >> watcher object)? How to represent data from profiles which are not >> "measurement" based? > > I suppose you were directing this at Rafal and not me? I don't think it > makes sense to merge these. I was only saying that the interfaces should > go from Device to Adapter. No, I was commenting specifically on your suggestion to move RegisterWatcher() to the adapter path and have a "device" parameter to select the device. The user of this API would still need to check if the device actually supports that wanted GATT service (using the UUIDs device property) before registering any watcher. Regards, -- Anderson Lizardo Instituto Nokia de Tecnologia - INdT Manaus - Brazil -- 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
