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

Anderson,Luiz, 
 

Regarding caching reads and writes, the way LE works from my POV is
that most devices (except ones which rely on Proximity Link Loss) will
have Link Supervision Timeout of a few seconds at least. I have
already seen devices with 30 seconds LSTO.

For these high latency devices (which use conservative connection
parameters for saving battery) some caching is good. But we should
provide ways to let the D-Bus API user know whether the data has
effectively been written, or updated locally. This can be done by
means of D-Bus signals. Which point us back to the reason why we have
Value as a property in the first place.

Also imagine that the API might allow a couple of D-Bus clients
talking to the same device, but using different services. In case of
temporary link loss (or high latency), the values should be kept by
BlueZ, which will then write the value once connection is restored.
Otherwise, you would see many D-Bus clients trying to read/write data
while the link is not ok.

Caching seems very wrong to me. A client expects the correct data from the server, and not something that is not correct. Why provide a cached value instead of notifying the client that the link is down ? What if the server changes the value, and the client keeps getting the wrong value ? I believe the client should be notified if the link is down and there is an error reading the correct value.

Regarding the multiple client scenario - Since dbus is still not my expertise, I would be happy to get some ideas here - currently the function is blocking. It means that it will not return until the server replies or the link is down. I assume that the dbus daemon will queue multiple requests to allow bluetoothd to handle each one at it's turn ? If this is not the case, I would be happy if someone could elaborate on this and highlight the correct usage in multiple client scenario.

Luiz, while I totally agree with the D-Bus error instead of return
value (and you know about this stuff better than me :), how could we
pass the "custom"  ATT error codes to the client? Any profile can
define their own ATT error codes, and BlueZ cannot know all of them.

This is why I wanted it to be integer. 

quoted

Create an array of string WriteMethods which represents the methods
supported by the characteristic.

Agreed. They are readonly anyway. and makes it easier to extend.

I would just go with "SupportedWriteMethods" of something like that :)
(but it is a detail).

I also agree here. This property will be changed to writableMethods string array, with string>Boolean dictionary.

Thanks for your comments so far.

Chen Ganir.