From: Anderson Lizardo <anderson.lizardo@openbossa.org>
To: "Ganir, Chen" <chen.ganir@ti.com>
Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
Mat Martineau <mathewm@codeaurora.org>,
Claudio Takahasi <claudio.takahasi@openbossa.org>,
"linux-bluetooth@vger.kernel.org"
<linux-bluetooth@vger.kernel.org>,
"bgix@codeaurora.org" <bgix@codeaurora.org>,
"ingas@codeaurora.org" <ingas@codeaurora.org>
Subject: Re: GATT Dbus API on BlueZ - attirbute-api.txt modifications
Date: Thu, 27 Oct 2011 11:29:46 -0400 [thread overview]
Message-ID: <CAJdJm_NKmrx-qieUFMibPSL3L17=-nwKEjQrfvmf77HFsU8yaw@mail.gmail.com> (raw)
In-Reply-To: <7769C83744F2C34A841232EF77AEA20C01DCBC41E0@dnce01.ent.ti.com>
Hi Chen,
On Thu, Oct 27, 2011 at 11:06 AM, Ganir, Chen <chen.ganir@ti.com> wrote:
> Caching seems very wrong to me. A client expects the correct data from the server, and not something that is not correct. Why provide a cached value instead of notifying the client that the link is down ? What if the server changes the value, and the client keeps getting the wrong value ? I believe the client should be notified if the link is down and there is an error reading the correct value.
The value is not actually wrong, it is just old. But it is the best
data available while connection is not re-established. But as I said
before, there should be a way (e.g. specific D-Bus property) to the
user know that the value is stale, but it is not an error to have
"link down" temporarily.
For some data, the cached value is not bad. For others (e.g.
termomether measurements, timestamp information) it is. The API has to
be generic and allow to provide the latest available data, but still
allow user to know it is not "live" data.
Another point here is that we do not want to give to the D-Bus API use
the ability to control connections directly. In this scenario, what it
would do with a "link down" error?
If the BlueZ will try to reconnect on timeout anyway, why the user
needs to know about this temporary error? Of course the connection may
never be restored, in this case we can use a D-Bus "give up" signal to
notify this to the user.
> Regarding the multiple client scenario - Since dbus is still not my expertise, I would be happy to get some ideas here - currently the function is blocking. It means that it will not return until the server replies or the link is down. I assume that the dbus daemon will queue multiple requests to allow bluetoothd to handle each one at it's turn ? If this is not the case, I would be happy if someone could elaborate on this and highlight the correct usage in multiple client scenario.
Blocking D-Bus is not good as far as I know (Luiz and others may give
more details or ideas here, I'm newbie on d-bus as well).
Try to model the API on a way which is compatible with:
* high latency (e.g. 30 seconds)
* timeouts are common, but handled automatically by BlueZ.
* Not try to poll, or flood D-Bus with requests which cannot be
satisfied in real time.
>> > Create an array of string WriteMethods which represents the methods
>> > supported by the characteristic.
>>
>> Agreed. They are readonly anyway. and makes it easier to extend.
>>
>> I would just go with "SupportedWriteMethods" of something like that :)
>> (but it is a detail).
>>
> I also agree here. This property will be changed to writableMethods string array, with string>Boolean dictionary.
A dict is not needed here IMHO. If the string is on the array, it is
"true". If it is not, it is "false". I think this is how Luiz imagined
(right?).
Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
next prev parent reply other threads:[~2011-10-27 15:29 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-24 23:06 [PATCH bluez 0/2] Add BT 3.0+HS signalling definitions Peter Krystad
2011-10-24 23:06 ` [PATCH bluez 1/2] Add L2CAP Create/Move Channel definitions Peter Krystad
2011-10-24 23:06 ` [PATCH bluez 2/2] Add A2MP definitions Peter Krystad
2011-10-25 1:43 ` Add BT 3.0+HS signalling definitions Timur Mehrvarz
2011-10-25 7:38 ` GATT Dbus API on BlueZ Ganir, Chen
2011-10-25 12:52 ` Claudio Takahasi
2011-10-25 13:19 ` Ganir, Chen
2011-10-26 0:06 ` Claudio Takahasi
2011-10-26 7:20 ` GATT Dbus API on BlueZ - attirbute-api.txt modifications Ganir, Chen
2011-10-27 7:16 ` Mat Martineau
2011-10-27 8:22 ` Ganir, Chen
2011-10-27 11:30 ` Mat Martineau
2011-10-27 13:31 ` Luiz Augusto von Dentz
2011-10-27 13:57 ` Anderson Lizardo
2011-10-27 14:02 ` Anderson Lizardo
2011-10-27 14:58 ` Ganir, Chen
2011-10-27 15:13 ` Anderson Lizardo
2011-10-27 15:18 ` Ganir, Chen
2011-10-27 15:35 ` Anderson Lizardo
2011-10-27 15:06 ` Ganir, Chen
2011-10-27 15:29 ` Anderson Lizardo [this message]
2011-10-27 15:48 ` Ganir, Chen
2011-10-27 16:29 ` Anderson Lizardo
2011-10-27 16:47 ` Ganir, Chen
2011-10-27 17:32 ` Anderson Lizardo
2011-10-30 6:56 ` Ganir, Chen
2011-10-30 14:23 ` Anderson Lizardo
2011-10-30 15:48 ` Ganir, Chen
2011-10-30 18:02 ` Anderson Lizardo
2011-10-31 6:38 ` Ajay Pillai
2011-10-31 6:57 ` Ganir, Chen
2011-10-31 8:04 ` Ajay Pillai
2011-10-31 10:47 ` Anderson Lizardo
2011-10-31 7:19 ` Ganir, Chen
2011-10-31 11:07 ` Anderson Lizardo
2011-10-31 13:35 ` Ajay Pillai
2011-10-31 14:53 ` Luiz Augusto von Dentz
2011-10-28 16:19 ` Brian Gix
2011-10-28 20:09 ` Anderson Lizardo
2011-10-27 13:32 ` Anderson Lizardo
2011-10-31 17:41 ` Tsai, Mike
2012-01-11 14:25 ` GATT Dbus API on BlueZ Vijaykumar Dadmode
2012-01-11 14:57 ` Claudio Takahasi
2011-10-25 14:41 ` Add BT 3.0+HS signalling definitions Peter Krystad
2011-10-26 0:15 ` Timur Mehrvarz
2011-10-26 7:54 ` Andrei Emeltchenko
2011-10-27 13:39 ` BT 3.0+HS Timur Mehrvarz
2011-10-27 16:46 ` tim.howes
2011-11-03 16:38 ` Timur Mehrvarz
2011-10-26 7:36 ` [PATCH bluez 0/2] Add BT 3.0+HS signalling definitions Andrei Emeltchenko
2011-10-26 17:44 ` Peter Krystad
2011-10-27 8:00 ` 'Andrei Emeltchenko'
2011-10-28 0:23 ` Peter Krystad
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJdJm_NKmrx-qieUFMibPSL3L17=-nwKEjQrfvmf77HFsU8yaw@mail.gmail.com' \
--to=anderson.lizardo@openbossa.org \
--cc=bgix@codeaurora.org \
--cc=chen.ganir@ti.com \
--cc=claudio.takahasi@openbossa.org \
--cc=ingas@codeaurora.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
--cc=mathewm@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).