linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

      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).