All of lore.kernel.org
 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" <linux-bluetooth@vger.kernel.org>
Subject: Re: [PATCHv3 3/7] Add DBus OOB API documentation.
Date: Thu, 18 Nov 2010 15:45:39 +0200	[thread overview]
Message-ID: <20101118134539.GA5850@jh-x301> (raw)
In-Reply-To: <201011181151.48796.szymon.janc@tieto.com>

Hi Szymon,

On Thu, Nov 18, 2010, Szymon Janc wrote:
> OOB hierarchy
> =================
> 
> Service         unique name
> Interface       org.bluez.OOB

I suppose this should be called org.bluez.OobProvider, OobAgent or
something similar?

> Methods		array{byte} hash, array{byte} randomizer
> 			RequestRemoteOobData(object device)
> 
> 			This method gets called when the service daemon needs to
> 			get device's hash and randomizer for an OOB
> 			authentication. Each array should be 16 bytes long.
> 
> 			Possible errors: org.bluez.Error.NoData
> 
> 		void Release()
> 
> 			This method gets called when D-Bus plug-in for OOB was
> 			deactivated. There is no need to unregister provider,
> 			because when this method gets called it has already been
> 			unregistered.
> 
> --------------------------------------------------------------------------------
> 
> Service         org.bluez
> Interface       org.bluez.OOB

Interface definitions are supposed to be unique. You can't reuse the
same interface name for a different set of methods and signals.

> Object path     /

Regarding this, as you said the healt stuff is using /org/bluez. I'd
like to have someone who knows comment on the reasons why /org/bluez was
chosen instead of /. It seems inconsistent to me since the manager
interface uses /.

> --------------------------------------------------------------------------------
> 
> Service		org.bluez
> Interface	org.bluez.Adapter
> Object path	[variable prefix]/{hci0,hci1,...}
> 
> 		array{byte} hash, array{byte} randomizer ReadLocalOobData()

I agree that this is good to have in the Adapter path, but we can still
discuss about whether it should be on it's own interface or not. Maybe
reusing the adapter path is fine since we're only dealing with one
method in it.

> Service		unique name
> Interface	org.bluez.Agent
> Object path	freely definable
> 
> Methods		void RequestPairingApproval(object device)

I still like RequestPairing better (it's shorter). Marcel, do you have
any opinion or new suggestions for this? It would be reused for incoming
just-works pairing too (though only for 5.x).

Johan

  reply	other threads:[~2010-11-18 13:45 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-16 15:44 [PATCHv3 0/7] Support for out of band association model Szymon Janc
2010-11-16 15:44 ` [PATCHv3 1/7] Add support for Out of Band (OOB) " Szymon Janc
2010-11-16 16:16   ` Johan Hedberg
2010-11-16 15:44 ` [PATCHv3 2/7] Add DBus OOB plugin Szymon Janc
2010-11-16 16:30   ` Johan Hedberg
2010-11-16 15:44 ` [PATCHv3 3/7] Add DBus OOB API documentation Szymon Janc
2010-11-16 16:37   ` Johan Hedberg
2010-11-17 12:49     ` Szymon Janc
2010-11-18 10:51       ` Szymon Janc
2010-11-18 13:45         ` Johan Hedberg [this message]
2010-11-16 15:44 ` [PATCHv3 4/7] Add simple-oobprovider for testing Szymon Janc
2010-11-16 15:44 ` [PATCHv3 5/7] Add approval request for incoming pairing requests with OOB mechanism Szymon Janc
2010-11-16 16:24   ` Johan Hedberg
2010-11-17 16:03     ` Szymon Janc
2010-11-16 15:44 ` [PATCHv3 6/7] Update DBus OOB API with RequestApproval method Szymon Janc
2010-11-16 15:44 ` [PATCHv3 7/7] simple-agent - add RequestApproval method for OOB pairing Szymon Janc

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=20101118134539.GA5850@jh-x301 \
    --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 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.