bluetoothd specification

Quoted 1 line

Quoted 1 line

bluetoothd

Quoted 1 line

Quoted 1 line

SDP

Quoted 1 line

Quoted 1 line

PAN

Hi Marcel,

Periodic inquiry and adapter setup is extremely necessary for me. Is it possible set a high priority for these features?

Regarding the interfaces and objects path of the
bluetoothd my suggestion is:

Quoted 1 line

Quoted 1 line

Quoted 1 line

bluetoothd

DBus service :    org.bluez.hci
DBus interface:   org.bluez.hci
DBus object path: org/bluez/hci

- setup link properties
- setup inquiry mode
- kill bluetoothd
- show local adapters
- ???

Quoted 1 line

Quoted 1 line

Quoted 1 line

SDP

DBus service :    org.bluez.sdp
DBus interface:   org.bluez.sdp
DBus object path: org/bluez/sdp

methods:
- search
- register/unregister
- get local services
- ???

Quoted 1 line

Quoted 1 line

Quoted 1 line

PAN

DBus service :    org.bluez.pan
DBus interface:   org.bluez.pan
DBus object path: org/bluez/pan

- connect/disconnect
- listen start/stop
- connections

Open issues:
- How/Where handle multiple bluetooth adapters?
solution1: the device id (hci0) can be part of object path
eg: org.bluez.hci0.pan org.bluez.hci0.sdp

solution2: pass the device id as parameter or define a method
to set the active adapter.

I am not sure if it is better define a hierarchical objects or register multiples objects. Dbus support two functions:
dbus_connection_register_object_path and dbus_connection_register_fallback(for a given subsection of the object hierarchy). But I think that it is not important now because for both approachs the message handler functions are distinct. I will investigate more which approach is the best.

Defining an hierarchical approach make easier define policy/rules in the dbus configuration files.

Do you have a different design for it or suggestions?
There are a lot services that shall be inserted in the bluetoothd, maybe should be better define multiple interfaces(adapter, link, ... ) for this daemon.

Regards,
Claudio.

Hi Marcel,

I am sending a suggestion for bluetoothd implementation.

Please send your feedback.

Regarding the d-bus version checking, there is a different approach using pkg-config for check dbus version instead of verify if a function belongs to the dbus-1

The next step is implement the main loop.

Regards,
Claudio.

Quoted 80 lines · Claudio Takahasi

Hi Marcel,

Periodic inquiry and adapter setup is extremely necessary for me. Is it possible set a high priority for these features?

Regarding the interfaces and objects path of the
bluetoothd my suggestion is:

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

bluetoothd

DBus service :    org.bluez.hci
DBus interface:   org.bluez.hci
DBus object path: org/bluez/hci

- setup link properties
- setup inquiry mode
- kill bluetoothd
- show local adapters
- ???

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

SDP

DBus service :    org.bluez.sdp
DBus interface:   org.bluez.sdp
DBus object path: org/bluez/sdp

methods:
- search
- register/unregister
- get local services
- ???

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

PAN

DBus service :    org.bluez.pan
DBus interface:   org.bluez.pan
DBus object path: org/bluez/pan

- connect/disconnect
- listen start/stop
- connections

Open issues:
- How/Where handle multiple bluetooth adapters?
solution1: the device id (hci0) can be part of object path
eg: org.bluez.hci0.pan org.bluez.hci0.sdp

solution2: pass the device id as parameter or define a method
to set the active adapter.

I am not sure if it is better define a hierarchical objects or register multiples objects. Dbus support two functions:
dbus_connection_register_object_path and dbus_connection_register_fallback(for a given subsection of the object hierarchy). But I think that it is not important now because for both approachs the message handler functions are distinct. I will investigate more which approach is the best.

Defining an hierarchical approach make easier define policy/rules in the dbus configuration files.

Do you have a different design for it or suggestions?
There are a lot services that shall be inserted in the bluetoothd, maybe should be better define multiple interfaces(adapter, link, ... ) for this daemon.

Regards,
Claudio.

Hello,
=20
I think that it could be interesting to add interfaces to bluetoothd to manage paired devices like:
- get paired devices list
- remove paired device
=20
Regards
=20
Fred
=20
-----------------------------------------------
It is not by improving the oil lamp that one invents the electric bulb!
-----------------------------------------------
Danis Frederic PalmSource Europe
Software engineer
Mail : mailto:[email protected]
-----------------------------------------------
=20
=20
=20
Claudio Takahasi wrote:
=20

Quoted 11 lines

Hi Marcel,

I am sending a suggestion for bluetoothd implementation.

Please send your feedback.

Regarding the d-bus version checking, there is a different approach using pkg-config for check dbus version instead of verify if a function belongs to the dbus-1

Quoted 89 lines

The next step is implement the main loop.

Regards,
Claudio.

Quoted 80 lines · Claudio Takahasi

Hi Marcel,

Periodic inquiry and adapter setup is extremely necessary for me. Is it possible set a high priority for these features?

Regarding the interfaces and objects path of the
bluetoothd my suggestion is:

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

bluetoothd

DBus service :    org.bluez.hci
DBus interface:   org.bluez.hci
DBus object path: org/bluez/hci

- setup link properties
- setup inquiry mode
- kill bluetoothd
- show local adapters
- ???

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

SDP

DBus service :    org.bluez.sdp
DBus interface:   org.bluez.sdp
DBus object path: org/bluez/sdp

methods:
- search
- register/unregister
- get local services
- ???

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

PAN

DBus service :    org.bluez.pan
DBus interface:   org.bluez.pan
DBus object path: org/bluez/pan

- connect/disconnect
- listen start/stop
- connections

Open issues:
- How/Where handle multiple bluetooth adapters?
solution1: the device id (hci0) can be part of object path
eg: org.bluez.hci0.pan org.bluez.hci0.sdp

solution2: pass the device id as parameter or define a method
to set the active adapter.

I am not sure if it is better define a hierarchical objects or register multiples objects. Dbus support two functions:
dbus_connection_register_object_path and dbus_connection_register_fallback(for a given subsection of the object hierarchy). But I think that it is not important now because for both approachs the message handler functions are distinct. I will investigate more which approach is the best.

Defining an hierarchical approach make easier define policy/rules in the dbus configuration files.

Do you have a different design for it or suggestions?
There are a lot services that shall be inserted in the bluetoothd, maybe should be better define multiple interfaces(adapter, link, ... ) for this daemon.

Regards,
Claudio.

=20
=20
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclic=

_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Fred,

Thanks for your comment.
I will consider your suggestion. Currently, I am developing the main loop. This is the biggest challenge. The main loop function must be flexible in order to monitor a lot of file descriptors: D-Bus, periodic inquiry, incomming connections, ...

My ideia is develop the bluetoothd flexible, making possible enable/disable D-Bus service for the profiles(daemons: pand, dund, hidd ) at run-time.

If you have time, try analyze the architecture(skeleton) that I sent in the last patch and send me a feedback.

Regards,
Claudio.

Quoted 135 lines · Frederic Danis

Hello,

I think that it could be interesting to add interfaces to bluetoothd to manage paired devices like:
- get paired devices list
- remove paired device

Regards

Fred

-----------------------------------------------
It is not by improving the oil lamp that one invents the electric bulb!
-----------------------------------------------
Danis Frederic PalmSource Europe
Software engineer
Mail : mailto:[email protected]
-----------------------------------------------

Quoted 11 lines · Claudio Takahasi

Hi Marcel,

I am sending a suggestion for bluetoothd implementation.

Please send your feedback.

Regarding the d-bus version checking, there is a different approach using pkg-config for check dbus version instead of verify if a function belongs to the dbus-1

Quoted 89 lines

The next step is implement the main loop.

Regards,
Claudio.

Quoted 80 lines · Claudio Takahasi

Hi Marcel,

Periodic inquiry and adapter setup is extremely necessary for me. Is it possible set a high priority for these features?

Regarding the interfaces and objects path of the
bluetoothd my suggestion is:

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

bluetoothd

DBus service :    org.bluez.hci
DBus interface:   org.bluez.hci
DBus object path: org/bluez/hci

- setup link properties
- setup inquiry mode
- kill bluetoothd
- show local adapters
- ???

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

SDP

DBus service :    org.bluez.sdp
DBus interface:   org.bluez.sdp
DBus object path: org/bluez/sdp

methods:
- search
- register/unregister
- get local services
- ???

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

PAN

DBus service :    org.bluez.pan
DBus interface:   org.bluez.pan
DBus object path: org/bluez/pan

- connect/disconnect
- listen start/stop
- connections

Open issues:
- How/Where handle multiple bluetooth adapters?
solution1: the device id (hci0) can be part of object path
eg: org.bluez.hci0.pan org.bluez.hci0.sdp

solution2: pass the device id as parameter or define a method
to set the active adapter.

I am not sure if it is better define a hierarchical objects or register multiples objects. Dbus support two functions:
dbus_connection_register_object_path and dbus_connection_register_fallback(for a given subsection of the object hierarchy). But I think that it is not important now because for both approachs the message handler functions are distinct. I will investigate more which approach is the best.

Defining an hierarchical approach make easier define policy/rules in the dbus configuration files.

Do you have a different design for it or suggestions?
There are a lot services that shall be inserted in the bluetoothd, maybe should be better define multiple interfaces(adapter, link, ... ) for this daemon.

Regards,
Claudio.

-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

I am sending a new patch of bluetoothd.

Marcel, if possible, send me a feedback.

The ideia behind this daemon is provide a modular
D-Bus implementation for Bluez. Profiles(pan, dund, hcid) and other services(sdp, hcitool, hciconfig) can be developed individualy. It is possible enable/disable this profile at run-time.

There are a lot of pieces missing. This is just a skeleton of the architecture. My ideia is export all current features of the bluez-utils daemons and tools using a D-Bus interface.

Hi Claudio,
=20

Quoted 3 lines

I am sending a new patch of bluetoothd.

Marcel, if possible, send me a feedback.

=20
I am still on the road and this means that the feedback will be very limited.
=20
The first thing is that you really need to follow the coding style. I can't go through all your code and change it. Using indent is no option, because in most cases it makes it worse. Take a look at my code and see how I placed the whitespaces etc.

=20
The second thing is that I don't like patches that also change autoconf and automake stuff. It seems you only need that for D-Bus workarounds. So it would be great to do this first. I don't like your way how you

handled it. So the best idea is to use the final D-Bus 1.0 API as a base. I know that it is not ready, but I think 0.35 is quite close. This is the API to go, because the old API will disapear after the final release. Basically we only need to take care of the old 0.23 API and for that we should have a compat.h file that defines missing or renamed functions. The use of "static inline" is your friend here. I also don't wanna check the D-Bus version. We check for available functions, because keeping track of the different version can get very ugly.

=20
My third thing is that we need to introduce a main event loop like Glib is doing. So what I think is, that we should provide a common watch implementation in watch.[ch]. This implementation must be thread-safe and independent from the bluetoothd. Integrating it directly into bluetoothd makes no sense, because in general it is only about watching file descriptors and then calling a callback function.

=20
I haven't looked at any other details of your patch, but we need to sort that out first. Otherwise it gets ugly for me to review your patch. =20

Quoted 7 lines

The ideia behind this daemon is provide a modular
D-Bus implementation for Bluez. Profiles(pan, dund, hcid) and other services(sdp, hcitool, hciconfig) can be developed individualy. It is possible enable/disable this profile at run-time.

There are a lot of pieces missing. This is just a skeleton of the architecture. My ideia is export all current features of the bluez-util=

Quoted 1 line

daemons and tools using a D-Bus interface.

=20
The idea is the same way I like to go, but I like to do one step at a time. My main focus is on HCI and SDP. The PAN and HID intergration is not so important for me at the moment.
=20
What we should design first is the HCI D-Bus interface for the methods and the signals. There is no need to name them like their HCI names, because I like to see the D-Bus interface as an abstracted interface for easy use from within other programs and especially from Python. The bluetoothd is responsible for executing the right HCI commands to perform a specific task. I think we should design our interface along the HAL interface.
=20

For the SDP I would like to see a complete SDP implementation inside bluetoothd, because this gives us the possibilty of SDP record caching. No application should be forced to do this by their own. And we can create an easier API to SDP. The current one is horrible. =20
I like to see some D-Bus interface proposals first, before getting too much into coding.
=20
Regards
=20
Marcel
=20

=20
=20
=20
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclic=

_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

I will fix it. The current patch is just a skeleton(draft) of my idea.

Basically only the function signature or name changed, the behaviour are the same. The current code is compatible with 0.23, 0.33 and 0.34. I didn't test the 0.35 version. But, I belive that we will not have problems. The current "configure"(2.18) file is using AC_CHECK_LIB, for check function availability. This is not so elegant too.
In my current implementation the version of D-Bus is checked by "configure". There is no references to changed functions in the code, I defined macros replacing the function name/signature according to D-Bus version.

The current main loop is exactly the same approach of Glib. bluetoothd supposes to be the main daemon, therefore it must
be the first D-Bus object of the hierarchy and the object resposible for start the connection, register the object, register filters, handle signals(Disconnect, NameOwnerChanged, NameAcquired ...) The file descriptor poll should be flexible in order to handle other file descriptors(socket for incomming connections, socket for hci packets). These are the assumptions that I considered.

I am not understanding how you plan integrate hcid and HAL. Could you give me more details?

HCI and SDP are essential to the others profiles. PAN is important to me because I am developing a network library to help multiplayer games developers and UPnP applications control bluetooth connections. I will create a document with the basic interfaces required and submit a for your analysis as son as possible. But I will keep coding because I have a schedule to follow.

Hi Claudio,
=20

Quoted 2 lines

I will fix it. The current patch is just a skeleton(draft) of my idea.

=20
very good.
=20

Quoted 3 lines

Basically only the function signature or name changed, the behaviour are the same. The current code is compatible with 0.23, 0.33 and 0.34. I didn't test the 0.35 version. But, I belive that we will not have pro=

Quoted 1 line

The current "configure"(2.18) file is using AC_CHECK_LIB, for check fun=

Quoted 2 lines

availability. This is not so elegant too.
In my current implementation the version of D-Bus is checked by "config=

Quoted 1 line

There is no references to changed functions in the code, I defined macr=

Quoted 1 line

replacing the function name/signature according to D-Bus version.

=20
I think you missed my point. If some function is not available in 0.23, but it is in 0.3x then implement it in compat.c via a "static inline" function covered by an "#ifdef".
=20
And I do think that the checking for a specific library is a good thing to do, because tracking specific versions is bad. And after D-Bus 1.0 is released I might remove all compat D-Bus function from the BlueZ source code.
=20

Quoted 7 lines

The current main loop is exactly the same approach of Glib. bluetoothd supposes to be the main daemon, therefore it must be the first D-Bus object of the hierarchy and the object resposible for start the connection, register the object, register filters, handle signals(Disconnect, NameOwnerChanged, NameAcquired ...) The file descriptor poll should be flexible in order to handle other file descriptors(socket for incomming connections, socket for hci packe=

Quoted 1 line

These are the assumptions that I considered.

=20
What has the D-Bus object to do with the event loop? The event loop is something that is provided by Glib and we need our own implementation. The bluetoothd then adds file descriptors to the watch and that's it. I don't see any need why D-Bus must be the first file descriptor in the list and so bluetoothd itself and the event loop implementation are independent from each other.
=20

Quoted 2 lines

I am not understanding how you plan integrate hcid and HAL. Could you give me more details?

=20
This is not what I said. I said that we should model the D-Bus methods and signals like the HAL people did.
=20

Quoted 1 line

HCI and SDP are essential to the others profiles. PAN is important to m=

Quoted 5 lines

because I am developing a network library to help multiplayer games developers and UPnP applications control bluetooth connections. I will create a document with the basic interfaces required and submit a for your analysis as son as possible. But I will keep coding because I have a schedule to follow.

=20
I can't do anything about your schedule. For it is important that we get a clean interface over D-Bus.
=20
Regards
=20
Marcel
=20
=20
=20
=20
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclic=

_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel