Hi Chaojie, > If we encounter one condition that the value is determine with the "Write Command" procedure which no response for client, should we expose this kind of property ? If we expose it, we have to write command to the remote and read value back immediately, then emit propertychanged signal if read value equals to write value(different from old one). > I don't think we should expose this value until we have done an initial read (either internally before we construct the D-Bus hierarchy or after a call to ReadValue) or via notification. I think we should just keep the property hidden until we know what the value is, even in the case of a write. > In your proposal , I think we also should read initial value from remote at the beginning of DBus Hierachy setup. Whatever "read", "notify", or "indicate" even write request to remote, only different value compared with exist cache value such as initial value, then bluez emit propertychanged signal. This would be good, right? > I'm not opposed to this, though we can only read the initial value if the characteristic supports reads. If the characteristic only supports notify or indicate, then we should wait until we receive the first notification/indication to expose the property and we keep it hidden until then. Cheers, Arman -- 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
