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. > > > > 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. -- 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
