Hi Chen, On Thu, Oct 27, 2011 at 11:06 AM, Ganir, Chen <chen.ganir@xxxxxx> wrote: > 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. The value is not actually wrong, it is just old. But it is the best data available while connection is not re-established. But as I said before, there should be a way (e.g. specific D-Bus property) to the user know that the value is stale, but it is not an error to have "link down" temporarily. For some data, the cached value is not bad. For others (e.g. termomether measurements, timestamp information) it is. The API has to be generic and allow to provide the latest available data, but still allow user to know it is not "live" data. Another point here is that we do not want to give to the D-Bus API use the ability to control connections directly. In this scenario, what it would do with a "link down" error? If the BlueZ will try to reconnect on timeout anyway, why the user needs to know about this temporary error? Of course the connection may never be restored, in this case we can use a D-Bus "give up" signal to notify this to the user. > 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. Blocking D-Bus is not good as far as I know (Luiz and others may give more details or ideas here, I'm newbie on d-bus as well). Try to model the API on a way which is compatible with: * high latency (e.g. 30 seconds) * timeouts are common, but handled automatically by BlueZ. * Not try to poll, or flood D-Bus with requests which cannot be satisfied in real time. >> > 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. A dict is not needed here IMHO. If the string is on the array, it is "true". If it is not, it is "false". I think this is how Luiz imagined (right?). 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
