All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arman Uguray <armansito@chromium.org>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: BlueZ development <linux-bluetooth@vger.kernel.org>,
	Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Subject: Re: [PATCH BlueZ 03/11] shared/gatt-client: Added initial skeleton and simple functions.
Date: Thu, 21 Aug 2014 15:17:49 -0700	[thread overview]
Message-ID: <CAHrH25QjQPpxkSJ-we=bSwSDNjzSbtF30qbobwRc9oynTfT1Bw@mail.gmail.com> (raw)
In-Reply-To: <BF6538CE-3F1E-4F73-8E9C-6BE256482E55@holtmann.org>

Hi Marcel,

> I do not like the fact of _new() an object and have to call _init() to use. Actually calling _new() should trigger all needed transaction. We might want to just do this:
>
>         client = bt_gatt_client_new(att, mtu);
>
> And it will start the service discovery right away. As I said, it is fine to start the service discovery and set the ready handler later. Since we are main loop and single threaded this is totally fine.
>

Sounds good to me.


>> My idea here was that each profile/plugin can register its own handler
>> for the handles that they are interested in and get notified of a
>> changed service. We could also have a single service changed handler
>> here and the daemon code can then use that to go and probe each
>> plugin/profile based on that.
>
> I am not sure about this. The services changed should be handled centrally in the client itself. It might be better than allow to register a changed notifier on the bt_gatt_service that we get.
>

What I meant here is that the client, as you said, will handle the
change internally by rediscovering the involved services, updating its
cache, and so on. It's nice to then notify the upper layer about the
changes that occurred so that they can perform any necessary updates
in their state.


> Lets not bring handles into the game right here. It might be better to push this detail to later when the code is more complete.
>

I will add code for this handler when I add the service change
handling later then. For now, I'll go ahead and remove the
register/unregister functions that I introduced.

-Arman

  reply	other threads:[~2014-08-21 22:17 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-20 20:15 [PATCH BlueZ 00/11] Introducing shared/gatt-client Arman Uguray
2014-08-20 20:15 ` [PATCH BlueZ 01/11] shared/gatt-helpers: Remove service, characteristic, descriptor structures Arman Uguray
2014-08-20 20:15 ` [PATCH BlueZ 02/11] shared/gatt-helpers: Added result count functions Arman Uguray
2014-08-20 20:15 ` [PATCH BlueZ 03/11] shared/gatt-client: Added initial skeleton and simple functions Arman Uguray
2014-08-21 13:23   ` Luiz Augusto von Dentz
2014-08-21 16:42     ` Arman Uguray
2014-08-21 18:35   ` Marcel Holtmann
2014-08-21 19:26     ` Arman Uguray
2014-08-21 20:22       ` Marcel Holtmann
2014-08-21 22:17         ` Arman Uguray [this message]
2014-08-20 20:15 ` [PATCH BlueZ 04/11] shared/att: Support multiple disconnect handlers Arman Uguray
2014-08-21 18:28   ` Marcel Holtmann
2014-08-20 20:15 ` [PATCH BlueZ 05/11] shared/att: Add BT_ATT_DEFAULT_LE_MTU macro Arman Uguray
2014-08-20 20:15 ` [PATCH BlueZ 06/11] shared/gatt-helpers: Fixed typo in callback args Arman Uguray
2014-08-20 20:15 ` [PATCH BlueZ 07/11] shared/gatt-client: Add bt_gatt_client_set_debug Arman Uguray
2014-08-20 20:15 ` [PATCH BlueZ 08/11] shared/gatt-client: Implement initial service discovery Arman Uguray
2014-08-20 20:15 ` [PATCH BlueZ 09/11] shared/gatt-client: Add service iterator functions Arman Uguray
2014-08-20 20:15 ` [PATCH BlueZ 10/11] shared/gatt-client: Implement characteristic discovery Arman Uguray
2014-08-20 20:15 ` [PATCH BlueZ 11/11] shared/gatt-client: Implement descriptor discovery Arman Uguray

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='CAHrH25QjQPpxkSJ-we=bSwSDNjzSbtF30qbobwRc9oynTfT1Bw@mail.gmail.com' \
    --to=armansito@chromium.org \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=luiz.dentz@gmail.com \
    --cc=marcel@holtmann.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 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.