Re: [Bluez-devel] D-Bus interfaces

Marcel Holtmann
2004-02-11T13:32:50Z

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.