Hi folks,

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.

Suggestions are welcome!

Regards,
Claudio.

On 7/18/05, Claudio Takahasi <cktakahasi@gmail.com> wrote:
> 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.
> 
> 
> On 7/18/05, Frederic Danis <frederic.danis@palmsource.com> wrote:
> > 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:frederic.danis@palmsource.com
> > -----------------------------------------------
> >
> >
> >
> > Claudio Takahasi wrote:
> >
> > >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.
> > >>
> > >>
> > >>
> > >
> >
> >
> > -------------------------------------------------------
> > 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
> > Bluez-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bluez-devel
> >
>