Re: [RFC v1 1/1] doc/gatt-api: New API properties and methods for the GATT D-Bus API.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Arman,

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

that is the beauty of properties with D-Bus Object Manager, we can actually also invalidate a property and tell the applications that it went away. So yes, initially the value should not be present. If we never read it, then there is no cached value. If we are connecting to a know device, then we only provide the value once we verified that the services have not changed.

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

Exactly. And with that it is nice for the application since it still does not have to learn any new tricks to get the value. It just sits there and waits until it shows up.

Regards

Marcel

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




[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux