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.

On 7/12/05, Claudio Takahasi <cktakahasi@gmail.com> wrote:
> 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:
> 
> >>>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
>     - ???
> >>>SDP
> DBus service :    org.bluez.sdp
> DBus interface:   org.bluez.sdp
> DBus object path: org/bluez/sdp
> methods:
>     - search
>     - register/unregister
>     - get local services
>     - ???
> 
> >>>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.
>