Re: GATT Dbus API on BlueZ - attirbute-api.txt modifications

Hi Ajay,

On Mon, Oct 31, 2011 at 2:38 AM, Ajay Pillai [off-list ref] wrote:

Hi Anderson,

quoted

What if this value changes on the server itself, and notification is not enabled? The client will need a way to poll the real time >values, and not use a stale or cached value which is a big mistake here.

quoted

(This is not how it works on current implementation, but we already

know that right?) You just keep reading the Value property in some
loop in your code:

quoted

while <blah>:
   read-Value-property

quoted

If the connection is up, the ATT commands will be sent as soon as
possible. If not, connection is triggered, and then the ATT read
request/command is sent, and then PropertyChanged signal (should be)
sent.

The problem I see with this approach is that the DBUS client does not get to know that the value that it got while doing a getProperty() is
the value remembered by BlueZ and not the one directly read from the server at that time and hence potentially a stale value. I think it is important because some DBUS clients may just want to ignore any potentially stale value and not process it until it gets a "Property changed" signal. Now in that case, the DBUS client may have to handle the situation where it may never get a "Property Changed" signal (because the connection did not go through), but there would be app specific ways of handling it and it may or may not involve just letting the user know the hard truth.
Hence I think it is crucial to let the DBUS App know what kind of value it is getting inorder to empower it to make decisions.

You are absolutely right here.

One alternative would be to let the "value" property always read from cache and a "readValue" API always read from a connection, so that the DBUS application can decide which DBUS operation to use based on its usecase. The "readValue" API must return the value if the connection is active, or else return a status code indicating that connection procedure has been triggered and later (once connection and read procedures are over) emit a signal (maybe "propertyChanged") to signal the read value.

Looks a sane option to me. And it would allow the problem of doing
potentially unnecessary ATT requests while issuing GetProperties(). I
think a Value property is still useful for "read once on every
connection." values such as Tx Power. But both can work without
conflict.

Best Regards,
-- 
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil