Ajay, > 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. > > 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. > Can you please try and think of a situation where a client may need the old value, knowing that it may not be the correct one? Why would anyone needing a value from the server need a cached value which has no meaning at the time of the "get_properties", knowing also that it should wait for the "property_changed" event ? This design is totally wrong, and may cause problems. I really see no reason for keeping the cached value. The correct behavior can be one of the two : 1. ReadValue method, blocking if a connection is up, returning the value, or returning some kind of error to let the client know that a value can not be read at the moment if the link is down or pending. 2. ReadValue method invokes a procedure for reading the value. A ReadValueComplete signal/watcher method is then raised when the value was actually read from the server (connection is successful). These should replace the "Value" property, removing it from the list. I would prefer method 1, since it's more straight forward, and allows the client to know exactly what is going on. BR Chen Ganir. -- 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
