Hi Folks,
while thinking about the best management interface and API for the new
Bluetooth library and utils I came to the conlusion that D-Bus is the
right way to go. My problem is now that I don't wanna link the Bluetooth
library itself with the D-Bus library. So what I was thinking of that we
extend the hcid to be a multiplexer with a D-Bus interface. So we have
the HCI raw socket and ioctl's for configuration and we can use the
D-Bus interface for this and also advanced things like PIN management
etc. My idea behind this is, that graphical interfaces like Gnome or KDE
only have to use the D-Bus for their stuff.
Proposals and comments?
Regards
Marcel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Phil,
tor 2004-02-19 klockan 17.48 skrev Phil Blundell:
> I don't think this is really an issue: text-based tools are probably
> going to be using dbus-send, which can take care of converting to
> binary representation from some convenient textual format. Or, for
> languages which have their own D-BUS bindings, it would be handled at
> that level. So we may as well use the D-BUS type system, rather than
> manually converting everything to and from text strings.
This would require applications to convert Bluetooth addresses to/from
an artificial byte array representation which in most cases doesn't have
any meaning nor usefulness for the applications anyway. This is not only
unneeded work, it's also harmful because it restricts the address format
at the application layer instead of the at proper protocol layer.
Consider the same address issue with ipv4: It's better for high-level
applications to use text addresses (e.g. "127.0.0.1") instead of four
byte arrays. It's not only more convenient, it also works when the
address format is extended with ipv6.
Fredrik
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
on Thu, Feb 19, 2004 at 04:52:27PM +0100, Fredrik Noring wrote:
> Marshalling of text addresses is probably negligible in a DBus context.
> It can potentially make the interface more accessible to text based
> tools such as Perl as configurarions, user input etc. are based on text
> addresses.
Hi Fredrik
I don't think this is really an issue: text-based tools are probably
going to be using dbus-send, which can take care of converting to
binary representation from some convenient textual format. Or, for
languages which have their own D-BUS bindings, it would be handled at
that level. So we may as well use the D-BUS type system, rather than
manually converting everything to and from text strings.
p.
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel
tis 2004-02-17 klockan 23.59 skrev Marcel Holtmann:
> Any other outstanding stuff before I prepare a new release?
I have a bunch of patches that extends hcid with D-Bus interfaces
and so on (see http://noring.nocrew.org/bluetooth/) which would be
very useful for the Gnome Bluetooth Configuration utility:
1. The "keytab" file for link keys
2. The "nametab" file for cached names
3. The D-Bus interface
4. The use of "hcid.conf" for configuration storage
Everything except (4) is implemented.
Fredrik
Hi Phil
m?n 2004-02-16 klockan 15.46 skrev Phil Blundell:
> Encoding it as an ASCII string would be another possibility, but this
> would generally make the marshalling/unmarshalling process more expensive,
> and doesn't really gain you anything.
Marshalling of text addresses is probably negligible in a DBus context.
It can potentially make the interface more accessible to text based
tools such as Perl as configurarions, user input etc. are based on text
addresses.
Fredrik
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Philip
ons 2004-02-18 klockan 01.29 skrev Philip Blundell:
> I agree that it's just a name, but I don't think it's necessarily
> appropriate for us to use the Bluetooth name just because that's the
> underlying technology.
I too had this discussion with Marcel on this list a week ago and I
agree with you: "org.bluez" appears to be the proper D-Bus prefix.
Fredrik
On Wed, 2004-02-18 at 00:17, Marcel Holtmann wrote:
> > Right, but BlueZ is the group defining the interface. Linux and FreeBSD
> > are not the only Bluetooth vendors, so I don't think it is appropriate
> > to use the bluetooth.org namespace.
>
> for me this is only a name and the technology behind it is Bluetooth, so
> I prefer to use org.bluetooth. That's it.
I agree that it's just a name, but I don't think it's necessarily
appropriate for us to use the Bluetooth name just because that's the
underlying technology. The reason for having the domain identifier is
to ensure unique naming, not to indicate the provenance of the
interface. Any other group that wanted to invent D-BUS bindings for
Bluetooth would be just as entitled as us to use the "org.bluetooth"
namespace. Not that I think this is especially likely to happen, but it
still seems like bad form to usurp those identifiers.
> I don't know, but I like to have a pseudo standard interface that can be
> used across free unix operating systems.
We can still have that within the org.bluez namespace.
p.
Hi Philip,
> > actually I don't care about the Bluetooth SIG. This interface is not
> > really BlueZ and Linux specific, because the FreeBSD stack can also make
> > use of it.
>
> Right, but BlueZ is the group defining the interface. Linux and FreeBSD
> are not the only Bluetooth vendors, so I don't think it is appropriate
> to use the bluetooth.org namespace.
for me this is only a name and the technology behind it is Bluetooth, so
I prefer to use org.bluetooth. That's it.
Personally I don't like this reversed domain stuff I have seen first
with the introduction of Java.
> Do you think that the FreeBSD people will have a problem using an
> interface that has "bluez" in the name?
I don't know, but I like to have a pseudo standard interface that can be
used across free unix operating systems.
Regards
Marcel
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Tue, 2004-02-17 at 23:57, Marcel Holtmann wrote:
> actually I don't care about the Bluetooth SIG. This interface is not
> really BlueZ and Linux specific, because the FreeBSD stack can also make
> use of it.
Right, but BlueZ is the group defining the interface. Linux and FreeBSD
are not the only Bluetooth vendors, so I don't think it is appropriate
to use the bluetooth.org namespace.
Do you think that the FreeBSD people will have a problem using an
interface that has "bluez" in the name?
p.
Hi Philip,
> > I prefer something like "org.bluetooth.pin.request".
>
> I don't think it'd be a good idea to use "org.bluetooth", unless you can
> get the bluetooth SIG to endorse the interface. But we could certainly
> use "org.bluez".
actually I don't care about the Bluetooth SIG. This interface is not
really BlueZ and Linux specific, because the FreeBSD stack can also make
use of it.
Regards
Marcel
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Philip,
> > I included your patch with a massive coding style change. Any other
> > outstanding stuff before I prepare a new release?
>
> Ah, cool. Nothing else from me.
before I forget it. This must be changed
#define SERVICE_NAME "org.handhelds.gpe.bluez"
#define INTERFACE_NAME SERVICE_NAME ".PinAgent"
#define REQUEST_NAME "PinRequest"
#define PATH_NAME "/org/handhelds/gpe/bluez/PinAgent"
I prefer something like "org.bluetooth.pin.request".
Regards
Marcel
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Tue, 2004-02-17 at 23:44, Marcel Holtmann wrote:
> I prefer something like "org.bluetooth.pin.request".
I don't think it'd be a good idea to use "org.bluetooth", unless you can
get the bluetooth SIG to endorse the interface. But we could certainly
use "org.bluez".
p.
On Tue, 2004-02-17 at 22:59, Marcel Holtmann wrote:
> I included your patch with a massive coding style change. Any other
> outstanding stuff before I prepare a new release?
Hi Marcel
Ah, cool. Nothing else from me.
p.
Hi Phil,
> > btw I tried to integrate the D-Bus patch for the PIN-Helper, but got
> > compilation errors with the libraries from Debian Sid. Has anyone used
> > this patch on Debian Sid?
>
> Ah, yeah, you need an updated version to work with D-BUS 0.20. I think
> http://handhelds.org/~pb/bluez-utils-2.3-dbus-20040119.diff
> is the right file. The version of bluez-pin in Sid is already updated.
> Let me know if you still have trouble.
I included your patch with a massive coding style change. Any other
outstanding stuff before I prepare a new release?
Regards
Marcel
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
on Mon, Feb 16, 2004 at 04:36:15PM +0100, Marcel Holtmann wrote:
> btw I tried to integrate the D-Bus patch for the PIN-Helper, but got
> compilation errors with the libraries from Debian Sid. Has anyone used
> this patch on Debian Sid?
Ah, yeah, you need an updated version to work with D-BUS 0.20. I think
http://handhelds.org/~pb/bluez-utils-2.3-dbus-20040119.diff
is the right file. The version of bluez-pin in Sid is already updated.
Let me know if you still have trouble.
p.
Hi Phil,
> > I can only speak from my experience with dcop, but I would try to use standard
> > types whereever it's possible. In case that there exists a d-bus counterpart
> > to the dcop command line utility (dbus-send maybe?), it would make the bluez
> > interface more accessible for scripts.
>
> Yes, agreed. In my experiments with D-BUS and BlueZ so far, I've been
> using a simple byte array for the address. Encoding it as an ASCII
> string would be another possibility, but this would generally make the
> marshalling/unmarshalling process more expensive, and doesn't really
> gain you anything.
btw I tried to integrate the D-Bus patch for the PIN-Helper, but got
compilation errors with the libraries from Debian Sid. Has anyone used
this patch on Debian Sid?
Regards
Marcel
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
on Mon, Feb 09, 2004 at 12:15:24AM +0100, Fred Sch??ttgen wrote:
> On Sunday 08 February 2004 23:31, Marcel Holtmann wrote:
> > Do we need a special datatype for the BD_ADDR or is string the best?
>
> I can only speak from my experience with dcop, but I would try to use standard
> types whereever it's possible. In case that there exists a d-bus counterpart
> to the dcop command line utility (dbus-send maybe?), it would make the bluez
> interface more accessible for scripts.
Yes, agreed. In my experiments with D-BUS and BlueZ so far, I've been
using a simple byte array for the address. Encoding it as an ASCII
string would be another possibility, but this would generally make the
marshalling/unmarshalling process more expensive, and doesn't really
gain you anything.
p.
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Fredrik,
> I see. Yes, that would be better. When the device is reattached, this
> info may need to be updated in case something has changed though. But
> it's great to have it available "off-line" as read-only device metadata.
don't care about the update, because this is so easy :)
Regards
Marcel
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Fredrik,
> > I don't think so, because instead of (1) and (2) we need only a method
> > that returns the current attached devices.
> >
> > hci0 -> 11:22:33:44:55:66
> > hci2 -> aa:bb:cc:dd:ee:ff
> >
> > With this mapping the UI can do the rest.
>
> But device info like manufacturer isn't stored in the configuration,
> so you'll need the actual device for this. That's why both (1) and (2)
> are needed. (1) provides the list you gave above. (2) provides device
> info which isn't configurable. Yes?
No, we can store manufacturer, version, features etc. along with all
other device information. It is very easy to keep track of these. The
only difference with such informations is that they are read-only.
Regards
Marcel
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel,
On Thu, 2004-02-12 at 00:36, Marcel Holtmann wrote:
> No, we can store manufacturer, version, features etc. along with all
> other device information. It is very easy to keep track of these. The
> only difference with such informations is that they are read-only.
I see. Yes, that would be better. When the device is reattached, this
info may need to be updated in case something has changed though. But
it's great to have it available "off-line" as read-only device metadata.
Fredrik
Marcel,
On Thu, 2004-02-12 at 00:14, Marcel Holtmann wrote:
> I don't think so, because instead of (1) and (2) we need only a method
> that returns the current attached devices.
>
> hci0 -> 11:22:33:44:55:66
> hci2 -> aa:bb:cc:dd:ee:ff
>
> With this mapping the UI can do the rest.
But device info like manufacturer isn't stored in the configuration,
so you'll need the actual device for this. That's why both (1) and (2)
are needed. (1) provides the list you gave above. (2) provides device
info which isn't configurable. Yes?
Fredrik
Hi Fredrik,
> > Why? If you want to deny a paring, you can click cancel on the PIN
> > request.
>
> Well, you might want to avoid DOS PIN attacks by evil neighbours.
this is more service specific. Maybe we add this later.
> > So lets combine these with (1) and (2). How to present it, is a problem
> > of the UI.
>
> (1) and (2) is about current devices, that may or may not be configured.
> This is about list/remove configurations, that may or may not have
> devices attached. It's not the same thing, really.
I don't think so, because instead of (1) and (2) we need only a method
that returns the current attached devices.
hci0 -> 11:22:33:44:55:66
hci2 -> aa:bb:cc:dd:ee:ff
With this mapping the UI can do the rest.
> > The pairing procedure should be run automaticly on the fist connect, so
> > we shouldn't care about it.
>
> Uh? You do need a scan to find other devices, don't you?
Yes, but let's talk about this later and concentrate on the device
configuration at the moment.
> > It sounds somekind weird, but it will help in some cases.
>
> I don't understand why. :)
Let's think about a HID keyboard at boot time. You can't input your PIN,
but the screen can display it. So you tell hcid about a one-time PIN and
try to connect to keyboard in range.
Another point is that some application may want to ask for the PIN
before the connect to the device.
Regards
Marcel
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel,
On Wed, 2004-02-11 at 23:42, Marcel Holtmann wrote:
> I tought you meant up/down as real actions.
Yes, that too. Set the device up/down as well as keep it up/down. That's
what the user expects from the GUI buttons up/down.
> Why? If you want to deny a paring, you can click cancel on the PIN
> request.
Well, you might want to avoid DOS PIN attacks by evil neighbours.
> So lets combine these with (1) and (2). How to present it, is a problem
> of the UI.
(1) and (2) is about current devices, that may or may not be configured.
This is about list/remove configurations, that may or may not have
devices attached. It's not the same thing, really.
> The pairing procedure should be run automaticly on the fist connect, so
> we shouldn't care about it.
Uh? You do need a scan to find other devices, don't you?
> Yes. Please look at the code that RedHat already ships.
Sure.
> It sounds somekind weird, but it will help in some cases.
I don't understand why. :)
Fredrik
Hi Fredrik,
> > > 3. Permanently configure device status (up/down).
> > Agreed. Put "reset" to this list.
>
> Uhu? Permanent reset? ;)
>
> > Maybe a flag for auto-up on/off per device would be nice.
>
> What do you mean?
>
> The intention was that when a device is permanently configured "down",
> it will be kept down regardless of reboots etc. It will only go up after
> using the other option, configuring it permanently "up". Then it will be
> kept up by hcid, after reboot etc. This is equivalent with having the
> "autoinit" option available per device, i.e. in the "device" parameter
> section.
I tought you meant up/down as real actions.
> > I don't think that we need that. The pairing mode from hcid can go away
> > and we should use multi every time.
>
> I agree with the once/multi thing. But isn't it useful to be able to
> disable/enable pairing, i.e. deny/accept all pairing requests?
Why? If you want to deny a paring, you can click cancel on the PIN
request. And of course you can mark your device as non-inquiryable and
non-pageable.
Remember these are client options. If we come to the service options we
can think about once/multi/deny thing againg, but for the client it
makes no sense.
> > > 7. List permanently stored configurations.
> > > 8. Remove permanently stored configurations.
> > What do you mean by permanently stored configurations?
>
> I mean what you asked above: Make it possible to list and configure
> previous attached devices. :) A "permanent configuration" is equivalent
> to having a configuration like "device 00:00:00:00:00:00 { ... }" in
> hcid.conf. (I know you want to have this in another database, but it
> would still be "equivalent" with this.)
So lets combine these with (1) and (2). How to present it, is a problem
of the UI.
> > > 12. Perform av device scan (this will also update the name cache).
> > We need something, but I am not sure how to do this. Let's put it at the
> > bottom of the list.
>
> Something is needed when a user wants to request a pairing procedure
> through DBus. I suspect the user would like to select a device to pair
> with first, i.e. do a scan.
The pairing procedure should be run automaticly on the fist connect, so
we shouldn't care about it.
> > The pairing procedure should work in background and if a PIN is needed a
> > PIN helper window should be opened. Maybe you should look at the
> > bluez-pin program on the internet and the D-Bus extensions for hcid.
>
> What do you mean? I suppose an application DBus callback would be needed
> to handle PIN requests.
Yes. Please look at the code that RedHat already ships.
> > The one-time PIN method is what I really want to have. So an application
> > can provide a previous entered PIN and send it to hcid. The hcid will
> > use this for the next PIN request (and don't call a PIN helper) and then
> > forget the PIN.
>
> This sounds a bit strange. Isn't the PIN an on-demand thing? I mean, the
> user expects to enter the PIN which will be used for the current pairing
> procedure?
It sounds somekind weird, but it will help in some cases.
Regards
Marcel
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Fredrik,
> > do we really need to store configurations based on the device id? I
> > think we should store them all based on the device address only.
>
> My opinion is that we can drop support for the "device hci0 { ... }"
> syntax since it's a bit confusing - Bluetooth devices are very address
> oriented so "device { ... }" and "device 00:00:00:00:00:00 { ... }"
> are enough. This would also simplify the configuration code in hcid,
> i.e. less risk for bugs.
I like to keep it, because it can be useful for embedded devices where
you have two or more Bluetooth dongles. However I started using it on
one of my test machines that have many dongles attached.
For the D-Bus interface and the Gnome or KDE frontend we should use
BD_ADDR based settings only.
Regards
Marcel
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel,
On Wed, 2004-02-11 at 23:29, Marcel Holtmann wrote:
> I like to keep it, because it can be useful for embedded devices where
> you have two or more Bluetooth dongles. However I started using it on
> one of my test machines that have many dongles attached.
>
> For the D-Bus interface and the Gnome or KDE frontend we should use
> BD_ADDR based settings only.
That's OK with me.
Fredrik
Marcel,
On Wed, 2004-02-11 at 18:05, Marcel Holtmann wrote:
> But I also think that we should make is possible to list and configure
> previous attached devices. So they can change settings and attach the
> device later.
Agreed. This is the intention of (4) - (10), see below.
> > 3. Permanently configure device status (up/down).
> Agreed. Put "reset" to this list.
Uhu? Permanent reset? ;)
> Maybe a flag for auto-up on/off per device would be nice.
What do you mean?
The intention was that when a device is permanently configured "down",
it will be kept down regardless of reboots etc. It will only go up after
using the other option, configuring it permanently "up". Then it will be
kept up by hcid, after reboot etc. This is equivalent with having the
"autoinit" option available per device, i.e. in the "device" parameter
section.
> I don't think that we need that. The pairing mode from hcid can go away
> and we should use multi every time.
I agree with the once/multi thing. But isn't it useful to be able to
disable/enable pairing, i.e. deny/accept all pairing requests?
> > 7. List permanently stored configurations.
> > 8. Remove permanently stored configurations.
> What do you mean by permanently stored configurations?
I mean what you asked above: Make it possible to list and configure
previous attached devices. :) A "permanent configuration" is equivalent
to having a configuration like "device 00:00:00:00:00:00 { ... }" in
hcid.conf. (I know you want to have this in another database, but it
would still be "equivalent" with this.)
> But we also need a method to set an alias name for a remote device.
Agreed, see (6) below.
> > 12. Perform av device scan (this will also update the name cache).
> We need something, but I am not sure how to do this. Let's put it at the
> bottom of the list.
Something is needed when a user wants to request a pairing procedure
through DBus. I suspect the user would like to select a device to pair
with first, i.e. do a scan.
> The pairing procedure should work in background and if a PIN is needed a
> PIN helper window should be opened. Maybe you should look at the
> bluez-pin program on the internet and the D-Bus extensions for hcid.
What do you mean? I suppose an application DBus callback would be needed
to handle PIN requests.
> The one-time PIN method is what I really want to have. So an application
> can provide a previous entered PIN and send it to hcid. The hcid will
> use this for the next PIN request (and don't call a PIN helper) and then
> forget the PIN.
This sounds a bit strange. Isn't the PIN an on-demand thing? I mean, the
user expects to enter the PIN which will be used for the current pairing
procedure?
Here's an updated list:
1. List devices currently attached.
2. Get info on devices currently attached (address, name,
manufacturer, type etc.)
3. Reset a device.
4. Permanently configure device status (up/down).
5. Permanently configure device name.
6. Permanently configure remote device name (alias).
7. Permanently configure device discoverability.
8. Permanently configure pair mode (accept multi, or deny all).
9. List permanently stored configurations.
10. Remove permanently stored configurations.
11. List devices which are paired.
12. Remove devices which are paired.
13. Request the name for a device address, if available in
the name cache.
14. Perform a pairing procedure (will update the name cache too).
15. Provide a one-time PIN during a pairing procedure.
16. Perform av device scan (this will also update the name cache).
Fredrik
Marcel,
On Wed, 2004-02-11 at 17:45, Marcel Holtmann wrote:
> do we really need to store configurations based on the device id? I
> think we should store them all based on the device address only.
My opinion is that we can drop support for the "device hci0 { ... }"
syntax since it's a bit confusing - Bluetooth devices are very address
oriented so "device { ... }" and "device 00:00:00:00:00:00 { ... }"
are enough. This would also simplify the configuration code in hcid,
i.e. less risk for bugs.
Hi Fredrik,
> Here are some basic requirements, I think, for a Gnome Bluetooth Configuration
> tool:
>
> 1. List devices currently attached.
> 2. Get info on devices currently attached (address, name, manufacturer,
> type etc.)
Agreed.
But I also think that we should make is possible to list and configure
previous attached devices. So they can change settings and attach the
device later.
> 3. Permanently configure device status (up/down).
Agreed. Put "reset" to this list.
Maybe a flag for auto-up on/off per device would be nice.
> 4. Permanently configure device name.
> 5. Permanently configure device discoverability (Iscan? Pscan? Which?)
Agreed.
> 6. Permanently configure pair mode (allow/disallow).
I don't think that we need that. The pairing mode from hcid can go away
and we should use multi every time.
If a specific service like PAN requests a pairing or not is out of scope
for the current interface. These a service specific settings.
> 7. List permanently stored configurations.
> 8. Remove permanently stored configurations.
What do you mean by permanently stored configurations?
> 9. List devices which are paired.
> 10. Remove devices which are paired.
Agreed.
> 11. Request the name for a device address, if available in the name cache.
Agreed.
But we also need a method to set an alias name for a remote device.
> 12. Perform av device scan (this will also update the name cache).
We need something, but I am not sure how to do this. Let's put it at the
bottom of the list.
Don't worry about the name cache. That is a very easy task for hcid.
> 13. Perform a pairing procedure (will update the name cache too).
> 14. Provide a one-time PIN during a pairing procedure.
The pairing procedure should work in background and if a PIN is needed a
PIN helper window should be opened. Maybe you should look at the
bluez-pin program on the internet and the D-Bus extensions for hcid.
The one-time PIN method is what I really want to have. So an application
can provide a previous entered PIN and send it to hcid. The hcid will
use this for the next PIN request (and don't call a PIN helper) and then
forget the PIN.
> (1) and (2) can possibly be solved without DBus, but the rest will require it.
It is possible, but we won't have it. D-Bus for everything ;)
Regards
Marcel
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Fredrik,
> When using "hci0", the setting will be permanently stored and used for
> all devices that become "hci0". When using "00:00:00:00:00:00", the
> device with that address will have that setting, regardless of the
> interface (hci0, hci1 or otherwise). Configurations based on addresses
> should have higher priority than those based on interfaces.
>
> The applications will have to be careful on how to use the references,
> unless we decide that configurations only will be stored on addresses
> regardless of the type reference used by the application.
do we really need to store configurations based on the device id? I
think we should store them all based on the device address only.
Regards
Marcel
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel,
ons 2004-02-11 klockan 14.28 skrev Marcel Holtmann:
> I think we should summarise what tasks an UI have to do and then design
> a D-Bus interface from it.
Here are some basic requirements, I think, for a Gnome Bluetooth Configuration
tool:
1. List devices currently attached.
2. Get info on devices currently attached (address, name, manufacturer,
type etc.)
3. Permanently configure device status (up/down).
4. Permanently configure device name.
5. Permanently configure device discoverability (Iscan? Pscan? Which?)
6. Permanently configure pair mode (allow/disallow).
7. List permanently stored configurations.
8. Remove permanently stored configurations.
9. List devices which are paired.
10. Remove devices which are paired.
11. Request the name for a device address, if available in the name cache.
12. Perform av device scan (this will also update the name cache).
13. Perform a pairing procedure (will update the name cache too).
14. Provide a one-time PIN during a pairing procedure.
(1) and (2) can possibly be solved without DBus, but the rest will require it.
Fredrik
Marcel,
ons 2004-02-11 klockan 14.32 skrev Marcel Holtmann:
> These are not needed in the D-Bus interface. The first parameter of a
> D-Bus method will be "string device" and can be "hci0" or a BD_ADDR and
> this is enough to identify the device and open the needed socket.
Agreed. For configuration management, the difference in reference is
very important:
When using "hci0", the setting will be permanently stored and used for
all devices that become "hci0". When using "00:00:00:00:00:00", the
device with that address will have that setting, regardless of the
interface (hci0, hci1 or otherwise). Configurations based on addresses
should have higher priority than those based on interfaces.
The applications will have to be careful on how to use the references,
unless we decide that configurations only will be stored on addresses
regardless of the type reference used by the application.
> The HCI don't defines anything on PIN or link key management, but a
> D-Bus interface should provide functions for it.
Agreed.
Fredrik
Hi Fredrik,
> This looks good but many HCI functions are perhaps a bit low level? These
> are probably OK:
>
> org.bluetooth.hci.devup
> org.bluetooth.hci.devdown
> org.bluetooth.hci.devreset
> org.bluetooth.hci.devinfo
> org.bluetooth.hci.set_pkt_type
> org.bluetooth.hci.set_link_policy
> org.bluetooth.hci.set_link_mode
> org.bluetooth.hci.write_local_name
> org.bluetooth.hci.read_local_name
> etc.
we don't have to use the HCI names for it. We can choose names that fit
a little bit more better.
> But these do not appear to be suited for a DBus interface because they deal
> with low level things like sockets:
>
> hci_open
> hci_close
> hci_recv
> hci_send_command
> hci_send_request
> hci_errno
> etc.
These are not needed in the D-Bus interface. The first parameter of a
D-Bus method will be "string device" and can be "hci0" or a BD_ADDR and
this is enough to identify the device and open the needed socket.
> Do you mean an extended subset of HCI? I'm not sure I understand, please
> explain. What will be omitted and what will be extended?
The HCI don't defines anything on PIN or link key management, but a
D-Bus interface should provide functions for it.
Regards
Marcel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Fredrik,
> It's important for the Gnome applications to be able to do both
> configuration and device management. These are two separate things.
>
> Configuration management is about the persistent configurations
> (past and present), basically those configrations stored in hcid.conf.
> The Gnome applications must be able to list, add, remove and modify
> such configurations.
>
> There may exist configurations for devices that are not attached, and
> there may also be devices attached that do not have any specific
> configuration. The Gnome applications must be able to deal with these
> kinds of situations intelligently.
>
> Device management is about the devices currently attached, basically
> a light version of the HCI functionality in the Bluetooth lib. The
> Gnome applications should be able to list, probe and control such
> devices, but probably only at a very basic/high level through DBus.
>
> Your idea of having device managment in "org.bluetooth.hci" is good,
> I think. However, we will have to decide on what that interface looks
> like, because as noted in my previous e-mail, the HCI is not straight
> forward for a DBus interface. Many things are too low-level.
>
> The configuration management is probably better suited for another
> interface, possibly "org.bluetooth.conf".
>
> Name caches, pairing etc. also have several requirements to address.
> For example, requesting a pairing procedure is a typical device management
> task. But managing paired devices (listing, removing etc.) is typically a
> configuration management kind of thing.
for the real device management on HCI level we don't need any other
interface. All that we need is in the Bluetooth library and the new
version of the library brings full 1.2 support.
What I expect from a D-Bus interface is that it hides the HCI low level
tasks and combines it with storing of settings etc. for later use. The
setting of the local device is a good example. You can do this with the
HCI API, but it will only set the name and after a reboot it is gone and
have done again. If you set the local name through the D-Bus interface
than this name will be stored in somekind of database and the low level
HCI API will be used to set it. On reboot the hcid will retrieve these
setting and set the local name.
The other important part is the trusted devices management, which is not
defined in any part of the Bluetooth specification. From the low level
stuff it is easy, because we have to store the link keys and send them
on requests. For the UI level the link key itself is unimportant, but
the trusted devices must be manageable.
I think we should summarise what tasks an UI have to do and then design
a D-Bus interface from it.
Regards
Marcel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel,
m?n 2004-02-09 klockan 11.38 skrev Marcel Holtmann:
> The goal is to have an interface that can be used by Gnome, KDE etc.
> without any proper knowledge of the running implementations and its
> configuration files. So this is not about hcid, this is about what do
> the UI applications need.
It's important for the Gnome applications to be able to do both
configuration and device management. These are two separate things.
Configuration management is about the persistent configurations
(past and present), basically those configrations stored in hcid.conf.
The Gnome applications must be able to list, add, remove and modify
such configurations.
There may exist configurations for devices that are not attached, and
there may also be devices attached that do not have any specific
configuration. The Gnome applications must be able to deal with these
kinds of situations intelligently.
Device management is about the devices currently attached, basically
a light version of the HCI functionality in the Bluetooth lib. The
Gnome applications should be able to list, probe and control such
devices, but probably only at a very basic/high level through DBus.
Your idea of having device managment in "org.bluetooth.hci" is good,
I think. However, we will have to decide on what that interface looks
like, because as noted in my previous e-mail, the HCI is not straight
forward for a DBus interface. Many things are too low-level.
The configuration management is probably better suited for another
interface, possibly "org.bluetooth.conf".
Name caches, pairing etc. also have several requirements to address.
For example, requesting a pairing procedure is a typical device management
task. But managing paired devices (listing, removing etc.) is typically a
configuration management kind of thing.
Comments?
Fredrik
Marcel,
m?n 2004-02-09 klockan 11.38 skrev Marcel Holtmann:
> The HCI is well defined in the Bluetooth specification and you can of
> course look at libs2. The source contains all defined HCI commands and
> events for Bluetoth 1.2.
This looks good but many HCI functions are perhaps a bit low level? These
are probably OK:
org.bluetooth.hci.devup
org.bluetooth.hci.devdown
org.bluetooth.hci.devreset
org.bluetooth.hci.devinfo
org.bluetooth.hci.set_pkt_type
org.bluetooth.hci.set_link_policy
org.bluetooth.hci.set_link_mode
org.bluetooth.hci.write_local_name
org.bluetooth.hci.read_local_name
etc.
But these do not appear to be suited for a DBus interface because they deal
with low level things like sockets:
hci_open
hci_close
hci_recv
hci_send_command
hci_send_request
hci_errno
etc.
> We will provide a general and extend interface to the HCI functions,
> so we call it "hci".
Do you mean an extended subset of HCI? I'm not sure I understand, please
explain. What will be omitted and what will be extended?
Thanks,
Fredrik
Hi Fredrik,
> > I don't wanna support a config file which is intend to be editable by a
> > user and changable by a program. This is always a mess.
>
> That's actually the way many other configuration tools in Linux works...
> Like it or not, it's the simplest and most robust way to have it working
> because you will have to trust the administrator of the system for
> certain things anyway.
this is only true if the plain file itself is designed in somekind of
database format like /etc/passwd, but for hcid.conf that is not
acceptable. The format of hcid.conf is more flexible and if a user has
to edit this file, I don't wanna allow a program do edit it as well and
introduce its own format style.
> If the administrator decides to edit a system file, it's very likely
> because something really needs to be done. Hiding the real configuration
> files behind special binary databases is a true nightmare when stuff
> simply isn't working.
So we have to separate some settings.
> > We need to write a command line utility with full support anyway, because
> > the interface must be tested.
>
> Emacs/grep/awk/perl et. al. are much more powerful than most special
> tools. The user interfaces, DBus interfaces and tools only need to
> support the common cases when plain text files are used. This shouldn't
> stop anyone from actually implementing _all_ configuration features in some
> tool, but the advanced stuff can be also be left to the administrator.
If we want a clean interface for the configuration stuff that is not
covered by the HCI specification (like name cache etc.) we must go
through these interface in all cases, because the hcid implementation is
replaceable and the storage format also.
Regards
Marcel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Fredrik,
> > ask yourself what's the indentation of hcid.conf and how should a
> > computer program know about it. Of course this is possible to handle,
> > but it is always a mess.
>
> hcid can have some standard indentation style but it can also support
> the "--marcel-style" flag for your personal formating preferences. ;)
you don't got my point here. If a system administrator modifies some
settings in complex files like hcid.conf, everyone uses its own
identation and style to make it best readable for themself. And nobody
likes if a program changes a value and introduces some odd styles.
Config files like hcid.conf are build this way, because they can contain
complex configuration. Only the administrator should edit such files.
> > No. If we use a uniform storage, there is no need for a D-Bus interface,
> > because the application can modify the storage directly.
>
> "Plain text files" and "DBus interface" do not exclude each other. It
> would be great to have them both, because they serve different pruposes:
No they don't, but with an D-Bus interface we don't need to have
knowledge about these files, because this is the job of the program that
provides us with this D-Bus interface.
> Plain text files are great for admins, debugging, diagnostics etc.
>
> DBus is great for system tools, Gnome, KDE etc. Besides, the DBus
> interfaces provide a lot more services than just maintaining files.
I was never talking about D-Bus for file maintaining. I talked about a
general interface for different tasks. If it comes to link keys or name
caches, of couse these must be stored somewhere. But you can also store
them on a SQL database in another country. Who cares? That is beyond the
interface and its the job of the program that provides this interface.
> > One of the main ideas is to abstract from the storage of the information.
>
> Agreed. But storage abstraction does not implicate storage obfuscation,
> does it? :)
As already said, I have no problem with plain text files. But hcid.conf
is a configuration file and should only read once at startup. All other
modification have to stored in a configuration storage. If we have stuff
that overlaps, we must find a solution for it.
Regards
Marcel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Fredrik,
> > this is only true if the plain file itself is designed in somekind of
> > database format like /etc/passwd, but for hcid.conf that is not
> > acceptable. The format of hcid.conf is more flexible and if a user has
> > to edit this file, I don't wanna allow a program do edit it as well and
> > introduce its own format style.
>
> Why is the formating style a problem?
ask yourself what's the indentation of hcid.conf and how should a
computer program know about it. Of course this is possible to handle,
but it is always a mess.
> > So we have to separate some settings.
>
> Is the formating style issue the main reason for introducing a binary
> database instead of plain text?
No. This is the reason against letting hcid modify the hcid.conf. If the
settings are stored like in /etc/passwd or in a per-line basis I have no
problems with plain text files for this case.
> > If we want a clean interface for the configuration stuff that is not
> > covered by the HCI specification (like name cache etc.) we must go
> > through these interface in all cases, because the hcid implementation is
> > replaceable and the storage format also.
>
> It would be great to have file storage documented and part of the interface
> as well. Forcing specialized tools isn't flexible and user/admin friendly.
No. If we use a uniform storage, there is no need for a D-Bus interface,
because the application can modify the storage directly. One of the main
ideas is to abstract from the storage of the information. We provide an
interface to access and modify them and that must be enough.
Regards
Marcel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel,
m?n 2004-02-09 klockan 17.30 skrev Marcel Holtmann:
> If a system administrator modifies some settings in complex files like
> hcid.conf, everyone uses its own identation and style to make it best
> readable for themself. And nobody likes if a program changes a value
> and introduces some odd styles.
Well, I don't agree with you on this.
Having two configuration files, where one is non-editable, with some
kind of conflict management scheme between them does not make sense,
in my opinion.
hcid.conf isn't too complex to handle by hcid as well as being editable
and personal formating preferences simply isn't so important that hcid
shouldn't modify this file, I think.
Besides, if you don't use the Gnome/KDE tools for hcid, the config file
will not be modified anyway because the common DBus interfaces which use
name caches etc. have other files like the nametab/keytab files.
Fredrik
Hi Marcel
m?n 2004-02-09 klockan 16.46 skrev Marcel Holtmann:
> ask yourself what's the indentation of hcid.conf and how should a
> computer program know about it. Of course this is possible to handle,
> but it is always a mess.
hcid can have some standard indentation style but it can also support
the "--marcel-style" flag for your personal formating preferences. ;)
> No. If we use a uniform storage, there is no need for a D-Bus interface,
> because the application can modify the storage directly.
"Plain text files" and "DBus interface" do not exclude each other. It
would be great to have them both, because they serve different pruposes:
Plain text files are great for admins, debugging, diagnostics etc.
DBus is great for system tools, Gnome, KDE etc. Besides, the DBus
interfaces provide a lot more services than just maintaining files.
> One of the main ideas is to abstract from the storage of the information.
Agreed. But storage abstraction does not implicate storage obfuscation,
does it? :)
Fredrik
Marcel,
m?n 2004-02-09 klockan 14.01 skrev Marcel Holtmann:
> this is only true if the plain file itself is designed in somekind of
> database format like /etc/passwd, but for hcid.conf that is not
> acceptable. The format of hcid.conf is more flexible and if a user has
> to edit this file, I don't wanna allow a program do edit it as well and
> introduce its own format style.
Why is the formating style a problem?
> So we have to separate some settings.
Is the formating style issue the main reason for introducing a binary
database instead of plain text?
> If we want a clean interface for the configuration stuff that is not
> covered by the HCI specification (like name cache etc.) we must go
> through these interface in all cases, because the hcid implementation is
> replaceable and the storage format also.
It would be great to have file storage documented and part of the interface
as well. Forcing specialized tools isn't flexible and user/admin friendly.
Fredrik
Marcel,
m?n 2004-02-09 klockan 12.03 skrev Marcel Holtmann:
> I don't wanna support a config file which is intend to be editable by a
> user and changable by a program. This is always a mess.
That's actually the way many other configuration tools in Linux works...
Like it or not, it's the simplest and most robust way to have it working
because you will have to trust the administrator of the system for
certain things anyway.
If the administrator decides to edit a system file, it's very likely
because something really needs to be done. Hiding the real configuration
files behind special binary databases is a true nightmare when stuff
simply isn't working.
> We need to write a command line utility with full support anyway, because
> the interface must be tested.
Emacs/grep/awk/perl et. al. are much more powerful than most special
tools. The user interfaces, DBus interfaces and tools only need to
support the common cases when plain text files are used. This shouldn't
stop anyone from actually implementing _all_ configuration features in some
tool, but the advanced stuff can be also be left to the administrator.
Fredrik
Hi Fredrik,
> > I don't wanna support this. The hcid.conf file is a configuration file
> > for a default configuration and don't needs to read or stored through
> > the D-Bus interface. All modifications done through the D-Bus must be
> > stored in another file/database. The goal is to have an interface that
> > can be used by Gnome, KDE etc. ...
>
> This doesn't make sense. What happens when a user edits hcid.conf
> manually? It's simpler and straight forward to have exactly one config
> file which also can be edited manually if required. Please note that
> Gnome will most likely not expose _all_ HCI configuration features and
> that manual editing will be required to use these.
I don't wanna support a config file which is intend to be editable by a
user and changable by a program. This is always a mess.
The hcid.conf will provide the default settings for new devices or
special settings that are not in the database. If a setting is in the
database, this one will be used. The hcid.conf can also contain features
which we don't provide over a D-Bus interface. I don't have any problems
if the Gnome utility don't provide support for all HCI config stuff. We
need to write a command line utility with full support anyway, because
the interface must be tested.
Regards
Marcel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
m?n 2004-02-09 klockan 11.38 skrev Marcel Holtmann:
> I don't wanna support this. The hcid.conf file is a configuration file
> for a default configuration and don't needs to read or stored through
> the D-Bus interface. All modifications done through the D-Bus must be
> stored in another file/database. The goal is to have an interface that
> can be used by Gnome, KDE etc. ...
This doesn't make sense. What happens when a user edits hcid.conf
manually? It's simpler and straight forward to have exactly one config
file which also can be edited manually if required. Please note that
Gnome will most likely not expose _all_ HCI configuration features and
that manual editing will be required to use these.
> The HCI is well defined in the Bluetooth specification and you can of
> course look at libs2. The source contains all defined HCI commands and
> events for Bluetoth 1.2.
OK, thanks.
Fredrik
Hi Fredrik,
> > this actually depends on what you provide. The httpd provides the
> > implementation of the HTTP. We will provide a general and extend
> > interface to the HCI functions, so we call it "hci". The hcid is the
> > implementation of these functions on the server side.
>
> For example saving/loading the hcid configuration file (hcid.conf) isn't
> about HCI functions, is it? To include such out-of-HCI-scope functions,
> hcid should probably export interfaces beyond the HCI space:
I don't wanna support this. The hcid.conf file is a configuration file
for a default configuration and don't needs to read or stored through
the D-Bus interface. All modifications done through the D-Bus must be
stored in another file/database.
The goal is to have an interface that can be used by Gnome, KDE etc.
without any proper knowledge of the running implementations and its
configuration files. So this is not about hcid, this is about what do
the UI applications need.
> Can I ask you to provide a list of all the standard HCI functions? Is
> the syntax/parameters/semantics defined so that exactly one HCI interface
> implementation makes sense?
The HCI is well defined in the Bluetooth specification and you can of
course look at libs2. The source contains all defined HCI commands and
events for Bluetoth 1.2.
Regards
Marcel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel,
m?n 2004-02-09 klockan 11.06 skrev Marcel Holtmann:
> this actually depends on what you provide. The httpd provides the
> implementation of the HTTP. We will provide a general and extend
> interface to the HCI functions, so we call it "hci". The hcid is the
> implementation of these functions on the server side.
For example saving/loading the hcid configuration file (hcid.conf) isn't
about HCI functions, is it? To include such out-of-HCI-scope functions,
hcid should probably export interfaces beyond the HCI space:
org.bluetooth.hci, org.bluez.hci or org.bluez.hcid.hci
org.bluez.hcid.conf
org.bluez.hcid.fuzz
org.bluez.hcid.*
Can I ask you to provide a list of all the standard HCI functions? Is
the syntax/parameters/semantics defined so that exactly one HCI interface
implementation makes sense?
Many thanks,
Fredrik
Hi Fredrik,
> > not this way. I want to seperate the running services/profiles. The hcid
> > must serve "org.bluetooth.hci" as its base.
>
> What would the Apache webserver use? "org.w3c.http"? Something like
> "org.apache.httpd" fits better for a DBus interface. Similarly hcid
> ought to use "org.bluez.hcid", I think.
this actually depends on what you provide. The httpd provides the
implementation of the HTTP. We will provide a general and extend
interface to the HCI functions, so we call it "hci". The hcid is the
implementation of these functions on the server side.
Regards
Marcel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Mon, 2004-02-09 at 01:38, Marcel Holtmann wrote:
> not this way. I want to seperate the running services/profiles. The hcid
> must serve "org.bluetooth.hci" as its base.
What would the Apache webserver use? "org.w3c.http"? Something like
"org.apache.httpd" fits better for a DBus interface. Similarly hcid
ought to use "org.bluez.hcid", I think.
Fredrik
Hi Fredrik,
> We can perhaps have alteranative interfaces for different purposes, if
> the difference in semantics is large enough. For example a "standard"
> HCI interface with all such methods. (I'm not familiar with HCI myself.)
>
> For example: org.bluez.hci
>
> For stuff that doesn't fit within HCI, or becomes very akward, we
> can have other complementary interfaces. GUI applications have other
> needs than for example server applications, I suspect. Having
> several interfaces for the same things isn't ideal though, but some
> overlap for the sake of the HCI standard is perhaps a good idea?
>
> > Lets talk about the namespaces you are thinking of. What makes sense to
> > separate?
>
> Some ideas:
>
> - Name services: including local device, paired and scanned
> names. Preferably using the same "lookup" function, because
> when searching for a name, applications don't want to bother
> where (local/remote/cache/whatever) the name comes from. Given
> a device address, simply return the name if it's readily
> available.
>
> Note that since initiating a scan is expensive, this ought
> to be a separate method call.
>
> Example: org.bluez.name
>
> - Key/pairing services: including requesting/receiving a pairing
> procedure, link key and PIN management.
>
> Example: org.bluez.link
>
> - (Local) device configuration services: activate/deactivate
> devices etc. Link modes? Classes? Or maybe org.bluez.hci will
> be enough for this?
>
> Example: org.bluez.device
not this way. I want to seperate the running services/profiles. The hcid
must serve "org.bluetooth.hci" as its base.
Regards
Marcel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Mon, 2004-02-09 at 00:19, Marcel Holtmann wrote:
> We try to implement Bluetooth so "org.bluetooth" is ok ;)
Well.. :)
> Do you mean contexts or contents?
I mean context as in "state" and "handle". A file descriptor is an
example of handle that is a reference to a state or object. The hcid
interface as proposed does not have any contexts/states/handles. It's
just name space separation (modularity) for a bunch of functions.
> I am not really convinced about your argument, because I prefer to have
> more in common with the HCI specification. But the HCI don't have any
> namespace. Let me think about.
We can perhaps have alteranative interfaces for different purposes, if
the difference in semantics is large enough. For example a "standard"
HCI interface with all such methods. (I'm not familiar with HCI myself.)
For example: org.bluez.hci
For stuff that doesn't fit within HCI, or becomes very akward, we
can have other complementary interfaces. GUI applications have other
needs than for example server applications, I suspect. Having
several interfaces for the same things isn't ideal though, but some
overlap for the sake of the HCI standard is perhaps a good idea?
> Lets talk about the namespaces you are thinking of. What makes sense to
> separate?
Some ideas:
- Name services: including local device, paired and scanned
names. Preferably using the same "lookup" function, because
when searching for a name, applications don't want to bother
where (local/remote/cache/whatever) the name comes from. Given
a device address, simply return the name if it's readily
available.
Note that since initiating a scan is expensive, this ought
to be a separate method call.
Example: org.bluez.name
- Key/pairing services: including requesting/receiving a pairing
procedure, link key and PIN management.
Example: org.bluez.link
- (Local) device configuration services: activate/deactivate
devices etc. Link modes? Classes? Or maybe org.bluez.hci will
be enough for this?
Example: org.bluez.device
Fredrik
Hi Fredrik,
> I'm talking about the DBus specification. See:
> http://freedesktop.org/Software/dbus/doc/dbus-specification.html
>
> Excerpt: "Before an application is able to send messages to other
> applications it must send the org.freedesktop.DBus.Hello message to
> the message bus service." ^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> I.e. the name is more about who implemented it than what it tries
> to implement.
We try to implement Bluetooth so "org.bluetooth" is ok ;)
> > This is about objects. It is an object oriented interface. You have
> > objects like "device", "nametab", keytab" etc. with their methods. What
> > we don't have is instances like "hci0", so we have to carry the device
> > as an parameter.
>
> But objects carry contexts. These modular interfaces carry no contexts,
> and therefore cannot possibly be objects. Modular interfaces is about
> keeping name spaces apart.
Do you mean contexts or contents?
> > Do we really need this? What are the advantages of objects? I prefer
> > differencing with the method names. For example like "get_local_name"
> > and "get_remote_name".
>
> Modules is the way to extend applications. Say someday somebody decides
> to do loadable modules in hcid, implementing completely new services.
> Naturally, these modules ought to have their own name spaces. That's
> what these interfaces are used for.
I am not really convinced about your argument, because I prefer to have
more in common with the HCI specification. But the HCI don't have any
namespace. Let me think about.
Lets talk about the namespaces you are thinking of. What makes sense to
separate?
Regards
Marcel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Sunday 08 February 2004 23:31, Marcel Holtmann wrote:
> Do we need a special datatype for the BD_ADDR or is string the best?
I can only speak from my experience with dcop, but I would try to use standard
types whereever it's possible. In case that there exists a d-bus counterpart
to the dcop command line utility (dbus-send maybe?), it would make the bluez
interface more accessible for scripts.
This (besides flexibility issues) is also the reason why I agree with Marcel
that "simple" return values, but more methods are better than one method that
returns all the information at once, using nested dictionaries or whatever.
greetings
Fred
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel
On Sun, 2004-02-08 at 23:31, Marcel Holtmann wrote:
> please be more specific. What files are you talking about?
I'm talking about the DBus specification. See:
http://freedesktop.org/Software/dbus/doc/dbus-specification.html
Excerpt: "Before an application is able to send messages to other
applications it must send the org.freedesktop.DBus.Hello message to
the message bus service." ^^^^^^^^^^^^^^^^^^^^^^^^^^
I.e. the name is more about who implemented it than what it tries
to implement.
> What stuff do UI interfaces need to get with one call?
The device listning on for example the main window in the Gnome
Bluetooth Configuration tool.
> Do we need a special datatype for the BD_ADDR or is string the best?
When using DBus, I think it's a good idea to stay with generic types
like int, string, dictionary and array. Makes it easier to use a wide
range of languages too.
> This is about objects. It is an object oriented interface. You have
> objects like "device", "nametab", keytab" etc. with their methods. What
> we don't have is instances like "hci0", so we have to carry the device
> as an parameter.
But objects carry contexts. These modular interfaces carry no contexts,
and therefore cannot possibly be objects. Modular interfaces is about
keeping name spaces apart.
> Do we really need this? What are the advantages of objects? I prefer
> differencing with the method names. For example like "get_local_name"
> and "get_remote_name".
Modules is the way to extend applications. Say someday somebody decides
to do loadable modules in hcid, implementing completely new services.
Naturally, these modules ought to have their own name spaces. That's
what these interfaces are used for.
Mixing it makes a mess. :)
Fredrik
Hi Fredrik,
> > It is Bluetooth we are talking about, so use "bluetooth.org" even if we
> > don't own the domain. I don't care, because it is only a name ;)
>
> Well, please look at the names Freedeskop uses in DBus for
> generic things like disconnect signals. They actually use the
> "freedesktop" interface. :)
please be more specific. What files are you talking about?
> > Why not a list of devices and then an extra method for every element? I
> > want to make this interface as open and as extendable as possible.
>
> The reason is efficiency and ease of use. It's much more efficient to
> get everything in one batch when this is what's needed anyway. The
> dictionaries make this method call extremely extendable. We can also
> add complementary method calls if needed.
What stuff do UI interfaces need to get with one call?
> > Of course, this is obvious. What format do we use for the parameter. You
> > show it as string. This means "hci0" or "11:22:33:44:55:66" or both?
>
> I think both should be allowed. Currently only "hciX" is implemented.
Agreed. This makes it easy to come from socket programming to the D-Bus
interface, because you can use the BD_ADDR you are also using for the
socket.
Do we need a special datatype for the BD_ADDR or is string the best?
> > Now you see that I don't really like the object oriented stuff. I see no
> > need for "keytab", "nametab" etc. I see this interface more as somekind
> > of multiplexing for HCI.
>
> This isn't about objects. It's about modularisation. The new hcid
> implementation is much more modular than the previous version, made to
> enable plugin modules/services. It's really a very good idea to keep
> conceptually different things like "key pairs" and "name lookups" apart,
> using different interfaces.
This is about objects. It is an object oriented interface. You have
objects like "device", "nametab", keytab" etc. with their methods. What
we don't have is instances like "hci0", so we have to carry the device
as an parameter.
Do we really need this? What are the advantages of objects? I prefer
differencing with the method names. For example like "get_local_name"
and "get_remote_name".
Regards
Marcel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel
On Sun, 2004-02-08 at 23:04, Marcel Holtmann wrote:
> This is my favourite and we should make it easy to substitute is with
> another storage backend. So the handheld or embedded people can use what
> they thing fits better.
I don't want to complain about your favourite DB, but isn't a binary
database engine like Berkely DB over engineering for storing a handful
of keys and device names? I mean, we're talking about maybe 50 entries
max for all common cases.
Textfiles can easily handle 1000+ entries of Bluetooth key pairs
and device names without problems.
> If we have a D-Bus interface, these files (databases) should only be
> modified by the hcid. It is easier to use the Berkeley DB, because you
> don't have to write everything by yourself. The database code includes
> locking stuff for free.
Text based storage is easy I'd say, and a proof of concept is already
implemented too in typically less than 200 lines of code each. :) For
the common cases Berkely DB is heavier, less accessible, and more
difficult to maintain and debug.
That's why I think Berekely DB should be an option, if required, but
not default storage.
Fredrik
Hi Marcel
On Sun, 2004-02-08 at 22:54, Marcel Holtmann wrote:
> It is Bluetooth we are talking about, so use "bluetooth.org" even if we
> don't own the domain. I don't care, because it is only a name ;)
Well, please look at the names Freedeskop uses in DBus for
generic things like disconnect signals. They actually use the
"freedesktop" interface. :)
> The interface is about access to a specific service or protocol, so I
> want to use "hci". The hcid is only the implementation of it. For the
> future I also think about having D-Bus interfaces for "sdp", "hid" etc.
OK.
> Why not a list of devices and then an extra method for every element? I
> want to make this interface as open and as extendable as possible.
The reason is efficiency and ease of use. It's much more efficient to
get everything in one batch when this is what's needed anyway. The
dictionaries make this method call extremely extendable. We can also
add complementary method calls if needed.
> Of course, this is obvious. What format do we use for the parameter. You
> show it as string. This means "hci0" or "11:22:33:44:55:66" or both?
I think both should be allowed. Currently only "hciX" is implemented.
> And I prefer also to have get_name. See comment above.
OK. Adding new methods is no problem.
> We must also have something for remote names, so set_local_name,
> get_remote_name etc. would maybe better.
Agreed, but these should not be implemented in the "device" interface
because this isn't a device property.
> I don't wanna use the name "keytab". Maybe "pairing_list". Something
> like "is_paired(src, dst)" would also be nice.
OK.
> Yes, but "delete" is too generic.
Not in a "key pair" context, I think.
> Now you see that I don't really like the object oriented stuff. I see no
> need for "keytab", "nametab" etc. I see this interface more as somekind
> of multiplexing for HCI.
This isn't about objects. It's about modularisation. The new hcid
implementation is much more modular than the previous version, made to
enable plugin modules/services. It's really a very good idea to keep
conceptually different things like "key pairs" and "name lookups" apart,
using different interfaces.
> Can these signal also give us the new values? Like the HCI events. For
> example local_name_changed().
Yes, signals can carry arguments.
Fredrik
Hi Fredrik,
> > My favourite storage is Berkeley DB.
>
> That's an interesting idea, you mentioned that before. Can you
> elaborate, please?
This is my favourite and we should make it easy to substitute is with
another storage backend. So the handheld or embedded people can use what
they thing fits better.
> Here are some advantages of using textfiles (as default) for hcid
> storage:
>
> 1. Textfiles are intuitive to use and debug because they work
> with any tool (emacs, grep, awk, perl etc.)
>
> 2. Small to medium size storage files have always been text
> files in Unix/Linux (/etc/passwd, /etc/hosts etc.)
>
> 3. Textfile routines are very lightweight and efficient.
If we have a D-Bus interface, these files (databases) should only be
modified by the hcid. It is easier to use the Berkeley DB, because you
don't have to write everything by yourself. The database code includes
locking stuff for free.
My idea is to have a plain text file for default configuration and a
database file with dynamic configuration.
/etc/bluetooth/hcid.conf
/etc/bluetooth/hcid.db
The "hcid.db" will store different databases in the same file, for
example link keys or devices names.
Regards
Marcel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Fredrik,
> Here's an initial draft proposal for hcid DBus interfaces (as
> currently implemented in hcid 2.4-fn8):
>
> service: "org.bluez.hcid",
> path: "/org/bluez/hcid/device
> interface: "org.bluez.hcid.device
I think of a more generic interface. Not everything is Linux or BlueZ
related ;)
service: "org.bluetooth.hci"
It is Bluetooth we are talking about, so use "bluetooth.org" even if we
don't own the domain. I don't care, because it is only a name ;)
The interface is about access to a specific service or protocol, so I
want to use "hci". The hcid is only the implementation of it. For the
future I also think about having D-Bus interfaces for "sdp", "hid" etc.
> // Returns a dictionary with hci devices
> // as keys. The values are dictionaries with
> // the configuration parameters. Example:
> //
> // { "hci0" : { "type" : "USB",
> // "addr" : "00:00:00:00:00:00",
> // "status" : "up",
> // "name" : "Fuzz",
> // "manufacturer" : "Company" },
> // "hci1" : { "type" : ... } }
> method: dict(string:dict(string:string)) list(void)
>
> // Returns a specific configuration dict with the
> // parameters as above.
> method: dict(string:string) get_conf(string hci_dev)
Why not a list of devices and then an extra method for every element? I
want to make this interface as open and as extendable as possible.
> // Activates an hci device.
> method: void up(string hci_dev)
>
> // Deactivates an hci device.
> method: void down(string hci_dev)
Of course, this is obvious. What format do we use for the parameter. You
show it as string. This means "hci0" or "11:22:33:44:55:66" or both?
> // Deactivates an hci device.
> method: void set_name(string hci_dev, string name)
And I prefer also to have get_name. See comment above.
We must also have something for remote names, so set_local_name,
get_remote_name etc. would maybe better.
> service: "org.bluez.hcid",
> path: "/org/bluez/hcid/keytab
> interface: "org.bluez.hcid.keytab
>
> // Returns an array with key pairs as a dictionaries.
> // Example:
> //
> // [ { "sba" : "00:00:00:00:00:00",
> // "dba" : "00:00:00:00:00:00" },
> // { "sba" : "00:00:00:00:00:00",
> // "dba" : "00:00:00:00:00:00" },
> // ... ]
> method: array(dict(string:string)) list(void|string hci_dev)
I don't wanna use the name "keytab". Maybe "pairing_list".
Something like "is_paired(src, dst)" would also be nice.
> // Deletes a link pair
> method: void delete(string sba, string dba)
Yes, but "delete" is too generic.
> service: "org.bluez.hcid",
> path: "/org/bluez/hcid/nametab
> interface: "org.bluez.hcid.nametab
>
> // Returns a device name or void
> method: void|string delete(string bdaddr)
As said above. "get_remote_name" and so "del_remote_name".
Now you see that I don't really like the object oriented stuff. I see no
need for "keytab", "nametab" etc. I see this interface more as somekind
of multiplexing for HCI.
> path: "/org/bluez/hcid
> interface: "org.bluez.hcid
>
> // Notifies applications that device configuration
> // has changed.
> signal: void device(void)
>
> // Notifies applications that trusted key configuration
> // has changed.
> signal: void keytab(void)
Can these signal also give us the new values? Like the HCI events. For
example local_name_changed().
Regards
Marcel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel,
Here's an initial draft proposal for hcid DBus interfaces (as
currently implemented in hcid 2.4-fn8):
service: "org.bluez.hcid",
path: "/org/bluez/hcid/device
interface: "org.bluez.hcid.device
// Returns a dictionary with hci devices
// as keys. The values are dictionaries with
// the configuration parameters. Example:
//
// { "hci0" : { "type" : "USB",
// "addr" : "00:00:00:00:00:00",
// "status" : "up",
// "name" : "Fuzz",
// "manufacturer" : "Company" },
// "hci1" : { "type" : ... } }
method: dict(string:dict(string:string)) list(void)
// Returns a specific configuration dict with the
// parameters as above.
method: dict(string:string) get_conf(string hci_dev)
// Activates an hci device.
method: void up(string hci_dev)
// Deactivates an hci device.
method: void down(string hci_dev)
// Deactivates an hci device.
method: void set_name(string hci_dev, string name)
service: "org.bluez.hcid",
path: "/org/bluez/hcid/keytab
interface: "org.bluez.hcid.keytab
// Returns an array with key pairs as a dictionaries.
// Example:
//
// [ { "sba" : "00:00:00:00:00:00",
// "dba" : "00:00:00:00:00:00" },
// { "sba" : "00:00:00:00:00:00",
// "dba" : "00:00:00:00:00:00" },
// ... ]
method: array(dict(string:string)) list(void|string hci_dev)
// Deletes a link pair
method: void delete(string sba, string dba)
service: "org.bluez.hcid",
path: "/org/bluez/hcid/nametab
interface: "org.bluez.hcid.nametab
// Returns a device name or void
method: void|string delete(string bdaddr)
path: "/org/bluez/hcid
interface: "org.bluez.hcid
// Notifies applications that device configuration
// has changed.
signal: void device(void)
// Notifies applications that trusted key configuration
// has changed.
signal: void keytab(void)
Fredrik
Hi Marcel
On Sun, 2004-02-08 at 20:09, Marcel Holtmann wrote:
> I already looked at your stuff. Nice work btw.
Thanks!
> At the moment I am more concerned on how the D-Bus interface should
> look like than a real implementation.
I will send you the interface proposal in another e-mail. It's largely
implemented and used by the Gnome Bluetooth Configuration tool already,
but it's possible to modify of course.
> You now that an important part for me is the security. For example a
> user can see what devices a paired and it can delete a pairing, but
> it don't have to see the link key itself. This is the job of the
> daemon that provides this interface. The same applies for changing
> device settings and storing them on the harddisk.
I agree. This is the way the new proposed hcid is implemented.
> My favourite storage is Berkeley DB.
That's an interesting idea, you mentioned that before. Can you
elaborate, please?
Here are some advantages of using textfiles (as default) for hcid
storage:
1. Textfiles are intuitive to use and debug because they work
with any tool (emacs, grep, awk, perl etc.)
2. Small to medium size storage files have always been text
files in Unix/Linux (/etc/passwd, /etc/hosts etc.)
3. Textfile routines are very lightweight and efficient.
Please understand that although it does work, applications should
use the DBus interface instead of manipulating these files directly.
Here's how it's implemented in the proposed hcid. The default location
of these files is something to discuss. File layout:
$ ls -l /etc/bluetooth/keytab*
-rw-r--r-- 1 root root 98 Feb 8 18:29 /etc/bluetooth/keytab
-rw-r--r-- 1 root root 147 Feb 8 16:56 /etc/bluetooth/keytab-
-rw------- 1 root root 138 Feb 8 18:29 /etc/bluetooth/keytab.shadow
-rw------- 1 root root 207 Feb 8 16:56 /etc/bluetooth/keytab.shadow-
$ ls -l /etc/bluetooth/nametab*
-rw-r--r-- 1 root root 115 Feb 8 16:00 /etc/bluetooth/nametab
-rw-r--r-- 1 root root 86 Feb 8 15:02 /etc/bluetooth/nametab-
The dash files ("keytab-" etc.) are backup files. The "keytab" file is
readable by all. The "keytab.shadow" is only r/w-able by root. Contents:
$ cat /etc/bluetooth/keytab
# sba dba type create time
00:03:C9:2A:C4:A8 00:07:E0:0C:1B:3F 0 1076252948
00:10:DC:E9:EF:20 00:80:37:AA:7A:DA 0 1076253156
$ cat /etc/bluetooth/keytab.shadow
# sba dba key
00:03:C9:2A:C4:A8 00:07:E0:0C:1B:3F 2f66d0364a1eea2fae680af948bb3299
00:10:DC:E9:EF:20 00:80:37:AA:7A:DA 2855bdc30b49254902d5deebe24c24ce
$ cat /etc/bluetooth/nametab
# bdaddr name
00:00:08:04:DE:C8 Fuzz Buzz
00:80:37:AA:7A:DA Fredrik T39
00:07:E0:0C:1B:3F Fredrik TT
Fredrik
Hi Fredrik,
> > My problem is now that I don't wanna link the Bluetooth library itself
> > with the D-Bus library. So what I was thinking of that we extend the
> > hcid to be a multiplexer with a D-Bus interface. So we have the HCI raw
> > socket and ioctl's for configuration and we can use the D-Bus interface
> > for this and also advanced things like PIN management etc. My idea behind
> > this is, that graphical interfaces like Gnome or KDE only have to use the
> > D-Bus for their stuff.
>
> I have implemented this in hcid, DBus sockets, Gnome configuration
> interface and so on. Please look at: http://noring.nocrew.org/bluetooth/
I already looked at your stuff. Nice work btw. At the moment I am more
concerned on how the D-Bus interface should look like than a real
implementation. You now that an important part for me is the security.
For example a user can see what devices a paired and it can delete a
pairing, but it don't have to see the link key itself. This is the job
of the daemon that provides this interface. The same applies for
changing device settings and storing them on the harddisk.
Another point is that I want to use the system message bus for it.
> > Proposals and comments?
>
> Later tonight, I'll write you a detailed description on what's already
> implemented on the hcid DBus interfaces, new configuration options, the
> nametab and keytab files etc. I'd like to discuss these things so that
> we can agree on the API:s etc.
My favourite storage is Berkeley DB.
Regards
Marcel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
HI Marcel
On Sun, 2004-02-08 at 19:35, Marcel Holtmann wrote:
> while thinking about the best management interface and API for the new
> Bluetooth library and utils I came to the conlusion that D-Bus is the
> right way to go.
Excellent choice, I believe so too. ;)
> My problem is now that I don't wanna link the Bluetooth library itself
> with the D-Bus library. So what I was thinking of that we extend the
> hcid to be a multiplexer with a D-Bus interface. So we have the HCI raw
> socket and ioctl's for configuration and we can use the D-Bus interface
> for this and also advanced things like PIN management etc. My idea behind
> this is, that graphical interfaces like Gnome or KDE only have to use the
> D-Bus for their stuff.
I have implemented this in hcid, DBus sockets, Gnome configuration
interface and so on. Please look at: http://noring.nocrew.org/bluetooth/
> Proposals and comments?
Later tonight, I'll write you a detailed description on what's already
implemented on the hcid DBus interfaces, new configuration options, the
nametab and keytab files etc. I'd like to discuss these things so that
we can agree on the API:s etc.
Here's the release notes for the Gnome Bluetooth Configuration tool
0.1.0, released today:
o All clickable buttons are actually working! This includes:
- Devices can be brought up and down by clicking
on the Activate/Deactivate buttons.
- Device names can be set by typing in the Name field.
- Trusted devices pop up instantly below the "Trusted
Devices" tab when paired, with both names and addresses.
- Trusted devices can be removed by clicking on the
"Remove" button.
- Devices pop up automatically in the device list
when inserted (USB etc.). Remove should work too.
o Installation target (--prefix) works with the glade file.
o A name cache is maintained by hcid in /etc/bluetooth/nametab.
The location of this file may change in the future, and
it will be configurable. The new "pair_name" option to hcid
(default "yes") makes hcid save the names of remote devices
when pairing.
Fredrik