From: Johan Hedberg <johan.hedberg@gmail.com>
To: Szymon Janc <szymon.janc@tieto.com>
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: [RFC v4 0/8] DBus OutOfBand API update
Date: Tue, 14 Aug 2012 12:30:11 +0300 [thread overview]
Message-ID: <20120814093011.GB1083@x220> (raw)
In-Reply-To: <1344854800-20972-1-git-send-email-szymon.janc@tieto.com>
Hi Szymon,
On Mon, Aug 13, 2012, Szymon Janc wrote:
> changes since V3:
> - remove of DeviceFound signal (rationale below)
> - remove of UUIDs from AddRemoteData dictionary
> - AlreadyPaired -> AlreadyExist error change
> - proposed implementation
>
>
> After some more thinking about OOB API I've decided that emitting
> DeviceFound signal when OOB data are provided is not the best thing to do.
>
> Typical usecase with dbusoob plugin is to provide oob data and either start
> pairing with CreatePairedDevice or wait for incoming pairing request. No need
> to emit DeviceFound as OOB provider is already aware of device address and can
> start pairing. If it doesn't provide pairing agent for device there will be
> fallback to adapter agent (which doesn't need to know anything about OOB
> channel).
>
>
> For UUIDs removal is similar - OOB provider already knows which UUIDs are
> supported by remote device and based on that can choose to pair or not. No
> need to provide that to bluetoothd as it would be only used in DeviceFound
> signal anyway.
>
> Comments are welcome.
>
> --
> BR
> Szymon Janc
>
> Szymon Janc (8):
> dbusoob: Update API
> dbusoob: Simplify remove_remote_data
> dbusoob: Change ReadLocalData to match new API
> dbusoob: Change AddRemoteData to match new API
> dbusoob: Add support for Class in AddRemoteData
> dbusoob: Add support for Name in AddRemoteData
> dbusoob: Reply with error if SSP is not supported
> Update test/test-oob to match new DBus OOB API
>
> doc/oob-api.txt | 59 ++++++++++++++--
> plugins/dbusoob.c | 193 +++++++++++++++++++++++++++++++++++++++++++++--------
> src/adapter.c | 5 ++
> src/adapter.h | 2 +
> src/mgmt.c | 7 ++
> src/mgmt.h | 2 +
> test/test-oob | 4 +-
> 7 files changed, 235 insertions(+), 37 deletions(-)
The patches look good to me and have now been applied upstream. Thanks.
Johan
prev parent reply other threads:[~2012-08-14 9:30 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-13 10:46 [RFC v4 0/8] DBus OutOfBand API update Szymon Janc
2012-08-13 10:46 ` [RFC v4 1/8] dbusoob: Update API Szymon Janc
2012-08-13 10:46 ` [RFC v4 2/8] dbusoob: Simplify remove_remote_data Szymon Janc
2012-08-13 10:46 ` [RFC v4 3/8] dbusoob: Change ReadLocalData to match new API Szymon Janc
2012-08-13 10:46 ` [RFC v4 4/8] dbusoob: Change AddRemoteData " Szymon Janc
2012-08-13 10:46 ` [RFC v4 5/8] dbusoob: Add support for Class in AddRemoteData Szymon Janc
2012-08-13 10:46 ` [RFC v4 6/8] dbusoob: Add support for Name " Szymon Janc
2012-08-13 10:46 ` [RFC v4 7/8] dbusoob: Reply with error if SSP is not supported Szymon Janc
2012-08-13 10:46 ` [RFC v4 8/8] Update test/test-oob to match new DBus OOB API Szymon Janc
2012-08-14 9:30 ` Johan Hedberg [this message]
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=20120814093011.GB1083@x220 \
--to=johan.hedberg@gmail.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=szymon.janc@tieto.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 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).