All of lore.kernel.org
 help / color / mirror / Atom feed
From: Claudio Takahasi <cktakahasi@gmail.com>
To: bluez-devel@lists.sourceforge.net
Subject: Re: [Bluez-devel] Re: bluetoothd specification
Date: Mon, 18 Jul 2005 13:46:33 -0300	[thread overview]
Message-ID: <e1effdeb05071809461382a01c@mail.gmail.com> (raw)
In-Reply-To: <42DBD4F5.8000805@palmsource.com>

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,
>=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:frederic.danis@palmsource.com
> -----------------------------------------------
>=20
>=20
>=20
> Claudio Takahasi wrote:
>=20
> >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.
> >>
> >>
> >>
> >
>=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=
k
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>


-------------------------------------------------------
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

  reply	other threads:[~2005-07-18 16:46 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-12 20:47 [Bluez-devel] bluetoothd specification Claudio Takahasi
2005-07-15 17:37 ` [Bluez-devel] " Claudio Takahasi
2005-07-18 16:12   ` Frederic Danis
2005-07-18 16:46     ` Claudio Takahasi [this message]
2005-07-26 16:31       ` [Bluez-devel] Re: bluetoothd specification - new patch Claudio Takahasi
2005-07-26 17:18         ` Marcel Holtmann
2005-07-26 19:06           ` Claudio Takahasi
2005-07-26 21:57             ` Marcel Holtmann
2005-07-28 14:08               ` Claudio Takahasi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e1effdeb05071809461382a01c@mail.gmail.com \
    --to=cktakahasi@gmail.com \
    --cc=bluez-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.