Skip to contentSkip to conversation

Big rename for the D-Bus API

Bluez-devel Marcel Holtmann 2 participants 6 messages Feb 27, 2006 Bluetooth drivers

lore
Share & tools
lore

Marcel Holtmann

author maintainer
#0 lore raw

Hi,

I just came to the conclusion that using org.bluez.Device for the local attached Bluetooth dongles etc. is not a good name. I would prefer to use org.bluez.Adapter and start renaming everything before the next release. Any comments?

Regards

Marcel

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

#1 lore raw

Hi Marcel,

Quoted 4 lines · Marcel Holtmann

I just came to the conclusion that using org.bluez.Device for the local attached Bluetooth dongles etc. is not a good name. I would prefer to use org.bluez.Adapter and start renaming everything before the next release. Any comments?

I'm fine with that. The current naming is because of the "let's imitate hald interface" decision. However, if you change "Device" to "Adapter", then I think that the methods and signals in the Manager path should also change to using Adapter instead of Device (currently we have ListDevices, DefaultDevice, DeviceAdded and DeviceRemoved).

Johan

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

author maintainer
#2 lore raw

Hi Johan,

Quoted 10 lines
Quoted 4 lines

I just came to the conclusion that using org.bluez.Device for the local attached Bluetooth dongles etc. is not a good name. I would prefer to use org.bluez.Adapter and start renaming everything before the next release. Any comments?

I'm fine with that. The current naming is because of the "let's imitate hald interface" decision. However, if you change "Device" to "Adapter", then I think that the methods and signals in the Manager path should also change to using Adapter instead of Device (currently we have ListDevices, DefaultDevice, DeviceAdded and DeviceRemoved).

that is correct. It will be a BIG rename, but I think it is worth it and we can use the Device interface for remote devices in the future.

Did you had a chance to look at the current code inside the CVS? Besides two or three missing methods, everything has been implemented.

Regards

Marcel

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

#3 lore raw

Hi Marcel,

Quoted 2 lines · Marcel Holtmann

Did you had a chance to look at the current code inside the CVS? Besides two or three missing methods, everything has been implemented.

I haven't really had time to look at the new code, mostly because I have been working with an obex server implementation lately (you'll get yet another patch for openobex from me today or tomorrow ;)

However, I took a quick look at the code and made two small fixes to the first issues that I found (attached). The first patch cleans up sys.stdout.write() ugliness in dbus-test (however the change is not tested since my python version doesn't like the "@dbus.decorators.explicitly_pass_message" stuff).

The second patch fixes the code path where hci_open_dev fails in the hcid_dbus_setname_complete function (othervice strncpy(name, pname, sizeof(name) - 1)) will try to access uninitialized memory).

Johan

Index: hcid/dbus-test
===================================================================
RCS file: /cvsroot/bluez/utils/hcid/dbus-test,v
retrieving revision 1.13

dbus-test +9 -19
diff -u -r1.13 dbus-test
@@ -103,7 +103,7 @@
     def dbus_dev_setup(self):
         if not self.dev_path:
             try:
-                self.dbus_mrg_setup()
+                self.dbus_mgr_setup()
                 self.dev_path = self.manager.DefaultDevice()
             except dbus.DBusException, e:
                 print 'Failed to get default device: %s' % e
@@ -136,7 +136,7 @@
             print 'Failed to setup signal handler for manager path: %s' % e
             sys.exit(1)
 
-    def dbus_mrg_setup(self):
+    def dbus_mgr_setup(self):
         self.manager_obj = self.bus.get_object('org.bluez', '/org/bluez/Manager')
         self.manager = dbus.Interface(self.manager_obj, 'org.bluez.Manager')
 
@@ -158,28 +158,18 @@
     @dbus.decorators.explicitly_pass_message
     def dev_signal_handler(*args, **keywords):
         dbus_message = keywords["dbus_message"]
-        member = dbus_message.get_member()
-        sys.stdout.write(member) 
-        sys.stdout.write(' - ') 
-        sys.stdout.write(dbus_message.get_path())
-        sys.stdout.write(': ')
+        print '%s - %s: ' % (dbus_message.get_member(), dbus_message.get_path()),
         for arg in args[1:]:
-            sys.stdout.write(arg)
-            sys.stdout.write('   ')
-        sys.stdout.write('\n')
-        sys.stdout.flush()
+            print '%s   ' % arg,
+        print
 
     @dbus.decorators.explicitly_pass_message
     def mgr_signal_handler(*args, **keywords):
         dbus_message = keywords["dbus_message"]
-        member = dbus_message.get_member()
-        sys.stdout.write(member) 
-        sys.stdout.write(': ')
+        print '%s: ' % dbus_messsage.get_member()
         for arg in args[1:]:
-            sys.stdout.write(arg)
-            sys.stdout.write('   ')
-        sys.stdout.write('\n')
-        sys.stdout.flush()
+            print '%s   ' % arg,
+        print
 
     def signal_cb(self, sig, frame):
         print 'Caught signal, exiting'
@@ -346,7 +336,7 @@
             print 'Listening for events...'
         elif self.cmd in mgr_cmds:
             try:
-                self.dbus_mrg_setup()
+                self.dbus_mgr_setup()
             except dbus.DBusException, e:
                 print 'Failed to setup manager interface: %s' % e
                 sys.exit(1)

Index: hcid/dbus.c
===================================================================
RCS file: /cvsroot/bluez/utils/hcid/dbus.c,v
retrieving revision 1.78

dbus.c +1 -1
diff -u -r1.78 dbus.c
@@ -1078,7 +1078,7 @@
 	dd = hci_open_dev(id);
 	if (dd < 0) {
 		syslog(LOG_ERR, "HCI device open failed: hci%d", id);
-		memset(&rq, 0, sizeof(rq));
+		memset(&rp, 0, sizeof(rp));
 	} else {
 		memset(&rq, 0, sizeof(rq));
 		rq.ogf    = OGF_HOST_CTL;
author maintainer
#4 lore raw

Hi Johan,

Quoted 6 lines
Quoted 2 lines

Did you had a chance to look at the current code inside the CVS? Besides two or three missing methods, everything has been implemented.

I haven't really had time to look at the new code, mostly because I have been working with an obex server implementation lately (you'll get yet another patch for openobex from me today or tomorrow ;)

go ahead. I have plans for another OpenOBEX release this week.

Quoted 9 lines

However, I took a quick look at the code and made two small fixes to the first issues that I found (attached). The first patch cleans up sys.stdout.write() ugliness in dbus-test (however the change is not tested since my python version doesn't like the "@dbus.decorators.explicitly_pass_message" stuff).

The second patch fixes the code path where hci_open_dev fails in the hcid_dbus_setname_complete function (othervice strncpy(name, pname, sizeof(name) - 1)) will try to access uninitialized memory).

both patches have been applied. Thanks.

Regards

Marcel

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

author maintainer
#5 lore raw
In reply to Johan Hedberg

Hi Johan,

Quoted 10 lines
Quoted 4 lines

I just came to the conclusion that using org.bluez.Device for the local attached Bluetooth dongles etc. is not a good name. I would prefer to use org.bluez.Adapter and start renaming everything before the next release. Any comments?

I'm fine with that. The current naming is because of the "let's imitate hald interface" decision. However, if you change "Device" to "Adapter", then I think that the methods and signals in the Manager path should also change to using Adapter instead of Device (currently we have ListDevices, DefaultDevice, DeviceAdded and DeviceRemoved).

it's done now. The only leftover thing is to rename dbus-device.c into dbus-adapter.c and then proceed. And we maybe need to update some function names, but that's totally internal.

Regards

Marcel

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel