Anderson > > Yes, I think read-only property is better. This way, it will mostly be > used to decide whether RegisterCharacteristicsWatcher() is supported > or not. Also see the Luiz suggestion of using a list of strings. It > allows easily extending these GATT properties on future. > I will add a string list called ValueChangeMethods and add Notify and Indicate as possible strings. > Regarding a new RegisterCharacteristicsWatcher() argument, I would > avoid it if we can for now. We could implicitly have a priority inside > BlueZ: > Ok, I'm good with this as well. > * if characteristic supports indication, use indication (usually, this > means the server needs to make sure the value was received, so it can > e.g. free that value from its internal memory). > * if characteristic supports notification, use notification > * else, make RegisterCharacteristicsWatcher() returns a D-Bus error. > > That way, if a characteristic happens to support both indication and > notification, it will always use indication. If in future we find that > unsuitable for some profile, this can be changed, but let's try to not > make things too complex now :) > I'll do that as well. > As a general suggestion, I propose you first get the API changes > "approved" and committed upstream, then proceed with code changes. > Unless you are comfortable with doing lots of rounds of patch > submissions (or you are planning only RFC to get early comments). > This is the purpose of this document. Early next week I'll send the modified API text with the changes made according to the comments, and get the approval. For now, my implementation is internal, and is mostly to support some other work I need to get done. Thanks, Chen Ganir. -- 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
