RE: GATT Dbus API on BlueZ - attirbute-api.txt modifications

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.