Return-Path: From: "Ganir, Chen" To: Ajay Pillai , Anderson Lizardo CC: Luiz Augusto von Dentz , Mat Martineau , Claudio Takahasi , "linux-bluetooth@vger.kernel.org" , "bgix@codeaurora.org" , "ingas@codeaurora.org" Date: Mon, 31 Oct 2011 07:57:37 +0100 Subject: RE: GATT Dbus API on BlueZ - attirbute-api.txt modifications Message-ID: <7769C83744F2C34A841232EF77AEA20C01DCBC482A@dnce01.ent.ti.com> References: <1319497579-8859-1-git-send-email-pkrystad@codeaurora.org> <4EA6143E.4000606@googlemail.com> <7769C83744F2C34A841232EF77AEA20C01DCAA8D28@dnce01.ent.ti.com> <7769C83744F2C34A841232EF77AEA20C01DCAA8F85@dnce01.ent.ti.com> <7769C83744F2C34A841232EF77AEA20C01DCAA9265@dnce01.ent.ti.com> <7769C83744F2C34A841232EF77AEA20C01DCBC3F03@dnce01.ent.ti.com> <7769C83744F2C34A841232EF77AEA20C01DCBC41E0@dnce01.ent.ti.com> <7769C83744F2C34A841232EF77AEA20C01DCBC4234@dnce01.ent.ti.com> <7769C83744F2C34A841232EF77AEA20C01DCBC4275@dnce01.ent.ti.com> <7769C83744F2C34A841232EF77AEA20C01DCBC472E@dnce01.ent.ti.com> <7769C83744F2C34A841232EF77AEA20C01DCBC47E3@dnce01.ent.ti.com> <8DCFA6B89B9E70418E47A2348D55495A4790BF0B@banasiexm01.ASIA.ROOT.PRI> In-Reply-To: <8DCFA6B89B9E70418E47A2348D55495A4790BF0B@banasiexm01.ASIA.ROOT.PRI> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Sender: linux-bluetooth-owner@vger.kernel.org List-ID: 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.