Big rename for the D-Bus API

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

Hi Marcel,

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

Hi Johan,

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

Hi Johan,

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

Hi Marcel,

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

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

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;

Hi Johan,

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

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