From: Marcel Holtmann <marcel@holtmann.org>
To: Scott James Remnant <scott@netsplit.com>
Cc: linux-bluetooth@vger.kernel.org, keybuk@chromium.org, hadess@hadess.net
Subject: Re: [RFC PATCHv2] autopair: add autopair plugin
Date: Mon, 30 Jan 2012 11:49:37 -0800 [thread overview]
Message-ID: <1327952977.1955.160.camel@aeonflux> (raw)
In-Reply-To: <1327448862-21964-1-git-send-email-scott@netsplit.com>
Hi Scott,
> This plugin handles automatically generating PIN codes for certain
> device types following rules specified in an XML file derived from
> that used by the GNOME Bluetooth wizard.
>
> The plugin deliberately ignores unknown elements and attributes so
> that this file can be extended by the UI, for example adding hints
> that pairing shouldn't be attempted for certain devices (e.g. mice)
> or other special pairing considerations.
>
> Should autopairing fail for a device, it is blacklisted and will
> be retried using the agent as usual. These blacklist files can be
> harvested by distributions in order to further improve the database.
> ---
> Makefile.am | 9 +
> acinclude.m4 | 6 +
> plugins/autopair.c | 363 +++++++++++++++++++++++++++++++++++++++++
> plugins/pin-code-database.xml | 174 ++++++++++++++++++++
> 4 files changed, 552 insertions(+), 0 deletions(-)
> create mode 100644 plugins/autopair.c
> create mode 100644 plugins/pin-code-database.xml
<snip>
> +<!--
> + The autopair plugin will match devices, following the order of the XML
> + file [1], on any combination of type, OUI, or name.
> +
> + [1]: So specific devices should be at the top, and generic ones at the bottom,
> + so settings for specific devices are overridden as expected.
> +-->
> +
> +<!DOCTYPE devices [
> + <!ELEMENT devices (device)+>
> + <!ELEMENT device EMPTY>
> + <!ATTLIST device type (any|mouse|tablet|keyboard|headset|headphones|audio|printer|network) "any">
> + <!ATTLIST device oui CDATA #IMPLIED>
> + <!ATTLIST device name CDATA #IMPLIED>
> + <!ATTLIST device pin CDATA #REQUIRED>
> +]>
I think we need to have a discussion on this database format first. I
honestly do not like it at all. It does matching and result handling in
a single XML element. That seems like a bad idea.
And in addition making pin attribute required and then trying to disable
PIN with "NULL" magic is something that I rather not have.
I am also wondering why this has to be XML and not simple key-value INI
style files.
Regards
Marcel
next prev parent reply other threads:[~2012-01-30 19:49 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-24 23:47 [RFC PATCHv2] autopair: add autopair plugin Scott James Remnant
2012-01-30 19:49 ` Marcel Holtmann [this message]
2012-01-30 20:05 ` Bastien Nocera
2012-01-30 21:42 ` Scott James Remnant
2012-01-30 22:33 ` Bastien Nocera
2012-01-30 22:35 ` Scott James Remnant
2012-01-30 23:03 ` Bastien Nocera
2012-01-30 23:10 ` Scott James Remnant
2012-02-15 17:57 ` David Herrmann
2012-02-15 19:18 ` Scott James Remnant
2012-01-30 21:40 ` Scott James Remnant
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=1327952977.1955.160.camel@aeonflux \
--to=marcel@holtmann.org \
--cc=hadess@hadess.net \
--cc=keybuk@chromium.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=scott@netsplit.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).