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=20
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
=20
solution2: pass the device id as parameter or define a method=20
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=20
dbus_connection_register_fallback(for a given subsection of the=20
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.=20
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, ... )=20
for this daemon.
Regards,
Claudio.
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
I wrote a draft document describing the D-Bus interfaces, path and methods
for BlueZ.=20
Please check if I am following your ideas.
You can download it from:
http://www.cin.ufpe.br/~ckt/bluez/
Regards,
Claudio
On 7/26/05, Marcel Holtmann <[email protected]> wrote:
> Hi Claudio,
>=20
> > I will fix it. The current patch is just a skeleton(draft)
> > of my idea.
>=20
> very good.
>=20
> > 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=
blems.
> > The current "configure"(2.18) file is using AC_CHECK_LIB, for check fun=
ction
> > availability. This is not so elegant too.
> > In my current implementation the version of D-Bus is checked by "config=
ure".
> > There is no references to changed functions in the code, I defined macr=
os
> > 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
> > 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=
ts).
> > 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
> > 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
> > HCI and SDP are essential to the others profiles. PAN is important to m=
e
> > 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=
k
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Claudio,
> I will fix it. The current patch is just a skeleton(draft)
> of my idea.
very good.
> 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.
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".
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.
> 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.
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.
> I am not understanding how you plan integrate hcid and HAL. Could you
> give me more details?
This is not what I said. I said that we should model the D-Bus methods
and signals like the HAL people did.
> 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.
I can't do anything about your schedule. For it is important that we get
a clean interface over D-Bus.
Regards
Marcel
-------------------------------------------------------
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
Hi Marcel,
On 7/26/05, Marcel Holtmann <[email protected]> wrote:
> Hi Claudio,
>=20
> > 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.
[Claudio Takahasi]
I will fix it. The current patch is just a skeleton(draft)
of my idea.
>=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.
[Claudio Takahasi]
Basically only the function signature or name changed, the behaviour=20
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 problem=
s.
The current "configure"(2.18) file is using AC_CHECK_LIB, for check functio=
n
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.
>=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.
[Claudio Takahasi]
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,=20
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.
>=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
> > 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=
s
> > 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
[Claudio Takahasi]
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=20
a for your analysis as son as possible. But I will keep coding because
I have a schedule to follow.
Regards,
Claudio.
> 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=
k
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Claudio,
> I am sending a new patch of bluetoothd.
>
> Marcel, if possible, send me a feedback.
I am still on the road and this means that the feedback will be very
limited.
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.
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.
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.
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.
> 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.
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.
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.
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.
I like to see some D-Bus interface proposals first, before getting too
much into coding.
Regards
Marcel
-------------------------------------------------------
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
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 <[email protected]> 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 <[email protected]> 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:[email protected]
> > -----------------------------------------------
> >
> >
> >
> > 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 <[email protected]> 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
> > [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.
On 7/18/05, Frederic Danis <[email protected]> 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:[email protected]
> -----------------------------------------------
>=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 <[email protected]> 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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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]
-----------------------------------------------
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 <[email protected]> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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 <[email protected]> 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.
>