From: Marcel Holtmann <marcel@holtmann.org>
To: bluez-devel@lists.sourceforge.net
Subject: Re: [Bluez-devel] Implementing the PIN helper support
Date: Tue, 21 Feb 2006 13:56:06 +0100 [thread overview]
Message-ID: <1140526566.10008.18.camel@localhost> (raw)
In-Reply-To: <20060221122147.GA10892@localhost.localdomain>
Hi Johan,
> > > Using org.bluez.Manager interface for registering the default handler
> > > seems to me extending too much its purpose compared to hald where we
> > > copied it from. The only purpose of the manager interface there is to
> > > allow local device discovery. Placing the default handler registration
> > > method at the interface org.bluez.Device (or org.bluez.Device.PinAgent)
> > > and object path /org/bluez/Device should be enough in my opinion. If you
> > > want to register a handler only for a specific local device then the
> > > exact path for that device (e.g. /org/bluez/Device/hci0) could be used.
> >
> > For the default handler the Manager interface makes perfect sense to me.
> > It has nothing to do with any device and it can be present even if no
> > Bluetooth device is attached at all. From me perspective we put every
> > non device specific things into the Manager interface. However I might
> > be missing something.
>
> Well, it depends how we define the purpose of the Manager interface :)
> If we say it's for "all stuff which is not device specific" then what you
> propose is ok. If we say it's only for local device discovery, as in
> hald, then the default handler registration shouldn't be in Manager.
>
> In my opinion non-device specific things could just use the root device
> path (/org/bluez/Device), while device specific stuff would use the
> exact device paths (e.g. /org/bluez/Device/hci0). But, I don't have any
> really strong opinion about this, so if you still insist on using
> Manager I wont complain anymore ;)
at the moment I don't have a strong opinion in any direction. I think we
need to choose something that looks sane from the client code.
> > > > Do we really only need the object path? I really like to get the default
> > > > handler thing implemented very soon.
> > >
> > > For the handler registration the object path should be enough. However
> > > we should probably rethink the org.bluez.PinAgent interface which
> > > currently consists of only one method: PinRequest.
> > >
> > > The PinRequest method currently takes two arguments: remote device
> > > address and a boolean indicating whether the connection is incomming or
> > > outgoing. A third parameter should probably be added for object path of
> > > the local device, since that information could be used for e.g. querying
> > > the name of the remote device.
> >
> > The interface must change. We use strings for the BD_ADDR now a clean
> > break is a good thing. Can you propose something?
>
> I'm not so convinced about the necessity of the "outgoing" boolean
> parameter, so depending on whether you want to keep it or not (we could
> add another device method for getting this information later) I'd
> propose one of the following:
> PinRequest(string bt_addr, string device_path)
> PinRequest(string bt_addr, string device_path, boolean outgoing)
>
> So a call could look like:
> PinRequest("11:22:33:44:55:66", "/org/bluez/Device/hci0")
the connection direction is not really helpful. Lets drop it for now.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
next prev parent reply other threads:[~2006-02-21 12:56 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-20 20:44 [Bluez-devel] Implementing the PIN helper support Marcel Holtmann
2006-02-20 21:14 ` Johan Hedberg
2006-02-20 21:31 ` Marcel Holtmann
2006-02-21 9:31 ` Johan Hedberg
2006-02-21 11:35 ` Marcel Holtmann
2006-02-21 12:21 ` Johan Hedberg
2006-02-21 12:56 ` Marcel Holtmann [this message]
2006-02-21 12:40 ` Claudio Takahasi
2006-02-21 13:02 ` Johan Hedberg
2006-02-21 13:10 ` Marcel Holtmann
2006-02-21 13:02 ` Marcel Holtmann
-- strict thread matches above, loose matches on Subject: below --
2006-02-20 20:48 Christopher E Piggott
2006-02-20 20:52 ` Marcel Holtmann
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=1140526566.10008.18.camel@localhost \
--to=marcel@holtmann.org \
--cc=bluez-devel@lists.sourceforge.net \
/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).