From: Vinicius Costa Gomes <vinicius.gomes@intel.com>
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
linux-bluetooth@vger.kernel.org
Subject: Re: [RFC BlueZ] doc/device-api: Replace GattServices with Discovering property
Date: Thu, 10 Mar 2016 15:04:52 -0300 [thread overview]
Message-ID: <878u1qi4zf.fsf@intel.com> (raw)
In-Reply-To: <1457626604-5656-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
Luiz Augusto von Dentz <luiz.dentz@gmail.com> writes:
> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
>
> GattServices is not really doing was it was meant to do which was to
> track progress of service discovery since it only worked for the very
> first time a device is connected but since we no longer remove the
> attributes an application would have the false impression the service are
> all resolved by the time it reconnects when in fact the service may have
> changed.
>
> Futhermore object tracking like it is doing has been obsolete by
> ObjectManager so this propose to replace the service discovery tracking
> with a boolean property which works both with SDP as well as GATT
> discovery.
> ---
> doc/device-api.txt | 9 +++------
> src/device.c | 58 +++++++++++-------------------------------------------
> 2 files changed, 14 insertions(+), 53 deletions(-)
>
> diff --git a/doc/device-api.txt b/doc/device-api.txt
> index a8076a2..9e58664 100644
> --- a/doc/device-api.txt
> +++ b/doc/device-api.txt
> @@ -212,10 +212,7 @@ Properties string Address [readonly]
> Service advertisement data. Keys are the UUIDs in
> string format followed by its byte array value.
>
> - array{object} GattServices [readonly, optional]
> + bool Discovering [readonly, optional, experimental]
>
> - List of GATT service object paths. Each referenced
> - object exports the org.bluez.GattService1 interface and
> - represents a remote GATT service. This property will be
> - updated once all remote GATT services of this device
> - have been discovered and exported over D-Bus.
> + Indicate whether or not service discovery is in
> + progress.
I wonder how useful it's going to be.
What I expect from a client is that it made a GetManagedObjects() call
when it entered the bus and added listeners to the InterfacesAdded(),
InterfacesRemoved() and PropertiesChanged() signals, I am not seeing
what kind of value this property is adding to that kind of client.
But yeah, it is better than GattServices.
Cheers,
--
Vinicius
next prev parent reply other threads:[~2016-03-10 18:04 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-10 16:16 [RFC BlueZ] doc/device-api: Replace GattServices with Discovering property Luiz Augusto von Dentz
2016-03-10 18:04 ` Vinicius Costa Gomes [this message]
2016-03-10 18:58 ` Luiz Augusto von Dentz
2016-03-11 11:05 ` Andrzej Kaczmarek
2016-03-11 11:23 ` Luiz Augusto von Dentz
2016-03-11 12:24 ` Andrzej Kaczmarek
2016-03-11 13:08 ` Luiz Augusto von Dentz
2016-03-11 13:41 ` Andrzej Kaczmarek
2016-03-11 14:39 ` Luiz Augusto von Dentz
2016-03-11 16:13 ` Andrzej Kaczmarek
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=878u1qi4zf.fsf@intel.com \
--to=vinicius.gomes@intel.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.