Hi Brian, On Fri, Oct 28, 2011 at 12:19 PM, Brian Gix <bgix@xxxxxxxxxxxxxx> wrote: > I am also of the opinion that caching is the wrong thing to do in > bluez/bluetoothd. I think you guys should take a look at how the GATT read/write on the generic D-Bus API is currently implemented (apologies if you done that already). I only used the "caching" word in my emails because it appeared at some point on this thread. What happens is not caching in the "CS" sense. It is more like "holding on a buffer". The value the client reads is the last read one, and he gets notified by means of PropertyChanged signal when the fresh value is read (after connection establishment). We should not block D-Bus calls where possible, as far as I know. For writes, the value is hold by BlueZ while is re-establishes connection. After the write is effective, a PropertyChanged is emitted (If I remember correctly). That way, the API is not blocking. The spec does not forbid the implementation to hold data in a buffer while the connection is being restored (please provide me reference if I am mistaken). > As to moving forward towards more characteristic definitions and profiles, a > do not think that by not caching, we will create the "poll fest" situation > that Luiz fears. Applications that have been written with LE in mind should > be the place where characteristic specific knowledge, such as persistence of > data over time, should be. An App that repeatedly polls a persistent > characteristic value would be poorly written (the App should do it's own > caching). In the unlikely event that Multiple Apps are sharing the same > remote server (which as a LE Use Case, I would consider Rare) you are only > increasing the Reads of persistent data on a 1 per App basis. Please take a look at Time, Phone Alert Status and Alert Notification profiles (specially their UCRDDs). BT SIG usually avoids creating dependencies between LE profiles, but these profiles are ones where it makes a lot of sense to be present on the same LE single mode device (and the corresponding support on the dual mode device). 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
