Hi,
We discussed on IRC with Claudio about the current D-BUS interface state
and decided that it would be good to have yet another thread about it.
The discussion actually started with me wondering about why there are
now two different DeviceList methods (one in the Device path and another
in the Manager path). It then evolved to the access control policies and
the differences between the Manager and Device paths.
It seems I hadn't really understood how the current design was meant to
to function, what internal assumptions there are, etc. I finally ended
up going through the HAL and NetworkManager[1] D-BUS interfaces and
comparing them with our current interface. As a result, here are some
ideas on how I think we should change the D-BUS interface.
[1] http://people.redhat.com/dcbw/NetworkManager/
We have borrowed the names "Manager" and "Device" from the HAL D-BUS
interface. However, they are currently used in a very different way than
in HAL (I'll explain this difference in the next paragraphs). This will
surely be quite confusing to someone trying to understand our interface
by relating to the HAL spec. In my opinion our options are to either not
use those names or to change the behaviour of our interface to be more
similar to HAL. I would suggest the latter.
As I mentioned, HAL has also a Manager and Device path. The Manager path
is used to discover available (local) devices, and not much else. It
provides methods for getting available device lists as well as signals
for removed or added devices. The actual device identifiers used by
these signals and methods are strings refering to D-BUS object paths
in the Device object path hierarchy. The objects in the Device object
path hierachy in turn represent the actual devices and provide
interfaces to perform different operations with them.
Our current interface design mixes these two functions: we have both
device discovery as well as device operations in both paths. To simplify
it (at least in my mind ;-), and to make it more similar to the HAL one,
I would suggest that we implement the following type of structure for
our interface:
Well-known path: /org/bluez/Manager
Interface: org.bluez.Manager
Methods: DeviceList, DefaultDevice
Signals: DeviceAdded, DeviceRemoved
The device identifiers used by the manager interface methods and signals
would be D-BUS object paths such as "/org/bluez/Device/hci0". To allow
discovering device sub-paths (e.g. "PAN" or "RFCOMM"), the Manager
interface could also provide an additional method which would return
the sub-paths as a string list.
I've also mentioned a new method, DefaultDevice, which would return a
string representing some real device path (or an error e.g.
"org.bluez.NoDevices"). Having a DefaultDevice method should simplify
the implementation since there's no need to handle the special case
of a default device path.
The toplevel device paths (e.g. "/org/bluez/Device/hci0", would
implement an interface "org.bluez.Device" which would provide a set of
methods that are common for all devices (if needed this could be split
up to several interfaces also, e.g. in a hcitool vs. hciconfig fashion).
The proposed changes wouldn't really change the current implemented
methods in any way - it would only change their place in the object
hierarchy. Well, actually that's not quite true: the DeviceList and
Device(Added|Removed) signals would start using object paths as device
identifiers instead of device names. One benefit of this is that we can
later shuffle around the structure of the Device path hierarchy without
introducing API incompatibilities.
Any comments?
Johan
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Johan,
> I just uploaded a new version which fixes listening for
> AuthenticationComplete events. However the attached patch is also
> required for hcid because othervice it doesn't send a proper method
> return to the Authenticate method call.
the patch is in the CVS now.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Wed, Nov 02, 2005, Johan Hedberg wrote:
> I've now uploaded the first version of the script here:
> http://www.iki.fi/~jhedberg/bluez-python/pybt.py
I just uploaded a new version which fixes listening for
AuthenticationComplete events. However the attached patch is also
required for hcid because othervice it doesn't send a proper method
return to the Authenticate method call.
Johan
On Tue, Nov 01, 2005, Johan Hedberg wrote:
> On Tue, Nov 01, 2005, Marcel Holtmann wrote:
> > I also like to add a test script that can utilize the complete API. I
> > don't wanna replace hciconfig or hcitool, but an easy script for testing
> > is really needed.
>
> I'll try to produce something. Hopefully I'll be able to send a first
> version to the list some time tomorrow.
I've now uploaded the first version of the script here:
http://www.iki.fi/~jhedberg/bluez-python/pybt.py
Here are some usage examples:
./pybt.py DeviceList
./pybt.py Inquiry
./pybt.py -i hci0 Inquiry 5 30
./pybt.py CancelInquiry
./pybt.py -i hci1 RemoteName 11:22:33:44:55:66
./pybt.py -i /org/bluez/Device/hci0 Up
./pybt.py -l
Johan
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
ext Marcel Holtmann wrote:
> Hi Eduardo,
>
>
>>here is the device Up and Down dbus methods.
>
>
> the patch is in the CVS now. However I am not sure about the future of
> any of these two methods. Do we really want the possibility to up and
> down a Bluetooth adapter?
>
Yes. At least in embedded devices it's useful for example when you need
offline mode.
--
Ville
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Tue, Nov 01, 2005, Marcel Holtmann wrote:
> For the test scripts, make sure that you include "#!/usr/bin/python" on
> the first line and I basically like one or two bigger test scripts. An
> extra script for every method is overkill.
I think I'll do just one big script. However, I think that
"#!/usr/bin/env python" is better because it will also work if python is
installed e.g. in /usr/local/bin.
Johan
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Tue, Nov 01, 2005, Marcel Holtmann wrote:
> I also like to add a test script that can utilize the complete API. I
> don't wanna replace hciconfig or hcitool, but an easy script for testing
> is really needed.
I'll try to produce something. Hopefully I'll be able to send a first
version to the list some time tomorrow.
Johan
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Eduardo,
> here is the device Up and Down dbus methods.
the patch is in the CVS now. However I am not sure about the future of
any of these two methods. Do we really want the possibility to up and
down a Bluetooth adapter?
For the test scripts, make sure that you include "#!/usr/bin/python" on
the first line and I basically like one or two bigger test scripts. An
extra script for every method is overkill.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
here is the device Up and Down dbus methods.
br,
Eduardo.
On 11/1/05, Marcel Holtmann <[email protected]> wrote:
> Hi Johan,
>
> > Here's the patch which implements the interface redesign. The change
> > ended up being a little bigger than I originally thought, but I think
> > the code and interface become more understandable this way. Attached is
> > also a simple python app which tests the DeviceList and DefaultDevice
> > methods.
>
> let's test this new interface. The patch is in the CVS now and we will
> see how it works out.
>
> I also like to add a test script that can utilize the complete API. I
> don't wanna replace hciconfig or hcitool, but an easy script for testing
> is really needed.
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
--
Eduardo Rocha
Instituto Nokia de Tecnologia - INdT
Hi Johan,
> Here's the patch which implements the interface redesign. The change
> ended up being a little bigger than I originally thought, but I think
> the code and interface become more understandable this way. Attached is
> also a simple python app which tests the DeviceList and DefaultDevice
> methods.
let's test this new interface. The patch is in the CVS now and we will
see how it works out.
I also like to add a test script that can utilize the complete API. I
don't wanna replace hciconfig or hcitool, but an easy script for testing
is really needed.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi,
Here's the patch which implements the interface redesign. The change
ended up being a little bigger than I originally thought, but I think
the code and interface become more understandable this way. Attached is
also a simple python app which tests the DeviceList and DefaultDevice
methods. I've also updated the pygtk test app to work with the new
interface:
http://www.iki.fi/~jhedberg/bluez-python/
On Tue, Nov 01, 2005, Claudio Takahasi wrote:
> Considering that local and remote configuration tasks will be
> available under the same path, we need change the child path
> register/unregister action. When a device is turned DOWN the path
> can't be unregistered anymore. We can use the attribute "status" of
> the struct "profile_obj_path_data" to control this. I think this
> attribute was initially added with this purpose :)
> Any comment? Does someone has another suggestion?
My idea is that we would use paths such as "/org/bluez/Device/hci0" for
the Up/Down stuff as well as other device configuration. The
"/org/bluez/Device/hci0/Controller" path in turn is used for the other
things and it us unregistered/registered during Down/Up events.
Johan
Hi,
These changes are very nice! The effort to change the paths will be small.
Now, /org/bluez/Device should be registered using a fallback approach
and this "root" path should reply for messages sent to a
invalid/unregistered device path. The Manager path, can be registered
as a normal path without care about child paths.
Considering that local and remote configuration tasks will be
available under the same path, we need change the child path
register/unregister action. When a device is turned DOWN the path
can't be unregistered anymore. We can use the attribute "status" of
the struct "profile_obj_path_data" to control this. I think this
attribute was initially added with this purpose :)
Any comment? Does someone has another suggestion?
Remove the default device path good, a default path was inserting
confusion when sending signals and replies.
Regards,
Claudio.
On 10/31/05, Johan Hedberg <[email protected]> wrote:
> Hi Marcel,
>
> On Tue, Nov 01, 2005, Marcel Holtmann wrote:
> > Feel free to send in a patch. For me these proposed changes are soundin=
g
> > perfectly sane and I am happy to try them out. However it would be grea=
t
> > if you can include some small test applications written in Python like
> > Eduardo did.
>
> Thanks for your encouraging reply! I don't yet have a patch for the
> changes, but I'll try to produce one during tommorow (Tuesday). I'll
> also try to provide some small python test apps as well as update the
> pygtk app I have been working on.
>
> Johan
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005
> Visit http://www.jboss.com/services/certification for more information
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
--
---------------------------------------------------------
Claudio Takahasi
Instituto Nokia de Tecnologia - INdT
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
On Tue, Nov 01, 2005, Marcel Holtmann wrote:
> Feel free to send in a patch. For me these proposed changes are sounding
> perfectly sane and I am happy to try them out. However it would be great
> if you can include some small test applications written in Python like
> Eduardo did.
Thanks for your encouraging reply! I don't yet have a patch for the
changes, but I'll try to produce one during tommorow (Tuesday). I'll
also try to provide some small python test apps as well as update the
pygtk app I have been working on.
Johan
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Johan,
> We discussed on IRC with Claudio about the current D-BUS interface state
> and decided that it would be good to have yet another thread about it.
> The discussion actually started with me wondering about why there are
> now two different DeviceList methods (one in the Device path and another
> in the Manager path). It then evolved to the access control policies and
> the differences between the Manager and Device paths.
>
> It seems I hadn't really understood how the current design was meant to
> to function, what internal assumptions there are, etc. I finally ended
> up going through the HAL and NetworkManager[1] D-BUS interfaces and
> comparing them with our current interface. As a result, here are some
> ideas on how I think we should change the D-BUS interface.
>
> [1] http://people.redhat.com/dcbw/NetworkManager/
>
> We have borrowed the names "Manager" and "Device" from the HAL D-BUS
> interface. However, they are currently used in a very different way than
> in HAL (I'll explain this difference in the next paragraphs). This will
> surely be quite confusing to someone trying to understand our interface
> by relating to the HAL spec. In my opinion our options are to either not
> use those names or to change the behaviour of our interface to be more
> similar to HAL. I would suggest the latter.
I think this is my fault, because I started proposing the names "Device"
and "Manager" and not taking care of that they are used in the same way
HAL is using them. I prefer to go with the HAL design. These guys have
the most experiences in using D-Bus (because it was written to support
the HAL idea in the first place) and their interface has been proofed in
real applications.
> As I mentioned, HAL has also a Manager and Device path. The Manager path
> is used to discover available (local) devices, and not much else. It
> provides methods for getting available device lists as well as signals
> for removed or added devices. The actual device identifiers used by
> these signals and methods are strings refering to D-BUS object paths
> in the Device object path hierarchy. The objects in the Device object
> path hierachy in turn represent the actual devices and provide
> interfaces to perform different operations with them.
>
> Our current interface design mixes these two functions: we have both
> device discovery as well as device operations in both paths. To simplify
> it (at least in my mind ;-), and to make it more similar to the HAL one,
> I would suggest that we implement the following type of structure for
> our interface:
>
> Well-known path: /org/bluez/Manager
> Interface: org.bluez.Manager
> Methods: DeviceList, DefaultDevice
> Signals: DeviceAdded, DeviceRemoved
Sound perfectly fine to me. Do you have a patch for this change?
> The device identifiers used by the manager interface methods and signals
> would be D-BUS object paths such as "/org/bluez/Device/hci0". To allow
> discovering device sub-paths (e.g. "PAN" or "RFCOMM"), the Manager
> interface could also provide an additional method which would return
> the sub-paths as a string list.
>
> I've also mentioned a new method, DefaultDevice, which would return a
> string representing some real device path (or an error e.g.
> "org.bluez.NoDevices"). Having a DefaultDevice method should simplify
> the implementation since there's no need to handle the special case
> of a default device path.
I also agree on this one.
> The toplevel device paths (e.g. "/org/bluez/Device/hci0", would
> implement an interface "org.bluez.Device" which would provide a set of
> methods that are common for all devices (if needed this could be split
> up to several interfaces also, e.g. in a hcitool vs. hciconfig fashion).
We need one interface to do the local device configuration and one for
the actual interaction with remote devices. This was the basic idea
behind the split into hcitool and hciconfig back then. And I think such
approach is still valid and useful.
> The proposed changes wouldn't really change the current implemented
> methods in any way - it would only change their place in the object
> hierarchy. Well, actually that's not quite true: the DeviceList and
> Device(Added|Removed) signals would start using object paths as device
> identifiers instead of device names. One benefit of this is that we can
> later shuffle around the structure of the Device path hierarchy without
> introducing API incompatibilities.
Feel free to send in a patch. For me these proposed changes are sounding
perfectly sane and I am happy to try them out. However it would be great
if you can include some small test applications written in Python like
Eduardo did.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel