Hi Ajay, On Mon, Oct 31, 2011 at 2:38 AM, Ajay Pillai <Ajay.Pillai@xxxxxxx> wrote: > Hi Anderson, > >> 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. > >>(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: > >>while <blah>: >> read-Value-property > >>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 -- 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
