From: "P. Durante" <shackan@gmail.com>
To: bluez-devel@lists.sourceforge.net
Subject: Re: [Bluez-devel] bluetoothd D-Bus interface proposals(draft 00.05)
Date: Mon, 22 Aug 2005 16:26:00 +0200 [thread overview]
Message-ID: <9307f5f2050822072659387e3b@mail.gmail.com> (raw)
In-Reply-To: <e1effdeb05082205517cac906c@mail.gmail.com>
On 8/22/05, Claudio Takahasi <cktakahasi@gmail.com> wrote:
> Hi Peter,
>=20
> I am planning provide a D-Bus service for setup a default adapter. But
> the developer will
> have to call a service to discover all available adapters. The steps shal=
l be:
> 1. Call a method to discover the available adapters
> org.bluez.bluetoothd.getAdapters will return a array of the
> available devices
>=20
That's exactly what I do now in org.bluetool.manager.ListDevices.
I was thinking if it's worth returning, for each adapter, together
with the device path, a boolean value indicating if the device is up
or not, so that applications can immediately check what adapters a
effectively 'available'
ps: I also added signals which are broadcasted when an interface is
brought up/down
Another big concern I'm having is about security, most hciconfig
commands require 'higher than normal' privileges to execute, should
the daemon allow certain requests only to the root user ? (luckily
dbus was conceived with security in mind, so adding such a policy
would not be difficult).
This would just make things more complicated and I don't think there's
any real gain in doing so, but maybe there are some security issues I
ignore at the moment, let me know your opinion.
(if for example, a program calls ListDevices to list the adapters, and
the user wants to use an interface which is not active, should the
program be allowed to bring it up?)
> 2. Call a method to setup the default adapter.
> org.bluez.bluetoothd.setDefaultAdapter, passing the adapter id
>=20
What if two (or more) applications chose, for whatever reason, to set
a different default adapter? If you *really* want such a mechanism,
maybe you should make such a method callable only by authorized code
(hence my dilemma above) or simply select the default adapter
internally in the daemon and don't expose this method at all.
> After that you will be able call the services passing the default path
>=20
> In the future we can try discover the best adapter to use and set it as
> default.
>=20
> Regards,
> Claudio.
>=20
>=20
Regards,
Paul
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
next prev parent reply other threads:[~2005-08-22 14:26 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-16 21:15 [Bluez-devel] bluetoothd D-Bus interface proposals(draft 00.05) Claudio Takahasi
2005-08-16 22:45 ` P. Durante
2005-08-18 12:05 ` Claudio Takahasi
2005-08-18 20:58 ` P. Durante
2005-08-19 17:27 ` Elvis Pfützenreuter
2005-08-22 11:17 ` Marcel Holtmann
2005-08-22 12:04 ` Elvis Pfützenreuter
2005-08-22 12:27 ` Claudio Takahasi
2005-08-22 12:37 ` Peter Robinson
2005-08-22 12:51 ` Claudio Takahasi
2005-08-22 14:26 ` P. Durante [this message]
2005-08-22 14:34 ` Marcel Holtmann
2005-08-22 17:39 ` Claudio Takahasi
2005-08-22 17:50 ` Marcel Holtmann
2005-08-22 19:47 ` Claudio Takahasi
2005-08-29 21:13 ` Claudio Takahasi
2005-08-29 21:46 ` Marcel Holtmann
2005-08-30 10:07 ` Paul Hedderly
2005-08-30 13:14 ` Claudio Takahasi
2005-08-30 18:16 ` Claudio Takahasi
2005-09-01 9:57 ` Marcel Holtmann
2005-08-22 14:29 ` Marcel Holtmann
2005-08-22 14:27 ` Marcel Holtmann
2005-08-22 14:21 ` 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=9307f5f2050822072659387e3b@mail.gmail.com \
--to=shackan@gmail.com \
--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 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.