Hi arman,
< Yes, we shouldn't expose the Value property if the characteristic properties field doesn't contain "read", "notify", or "indicate". With respect to caching the
< value before a write operation, I'm still hesitant towards making any assumptions about the value. I wouldn't want to cache the value until after the write
< operation has completed successfully (which is only possible to determine with the "write request" and "reliable long write" procedure) and there may be
< some race conditions where a characteristic might immediately change it's value and send a notification before we had a chance to store the write value. In
< this case the latest cached value would be incorrect.
<I understand that this is an edge case but it's enough to raise some concern.
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).
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?
Thanks
Chaojie
��.n��������+%������w��{.n�����{��� �^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
