[Bluez-devel] Big rename for the D-Bus API

[Bluez-devel] Big rename for the D-Bus API

[Marcel Holtmann]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Big rename for the D-Bus API

[Johan Hedberg]

Hi Marcel,

On Mon, Feb 27, 2006, Marcel Holtmann wrote:
> 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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Big rename for the D-Bus API

[Marcel Holtmann]

Hi Johan,

> > 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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Big rename for the D-Bus API

[Marcel Holtmann]

Hi Johan,

> > 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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Big rename for the D-Bus API

[Johan Hedberg]

[-- Attachment #1: Type: text/plain, Size: 909 bytes --]

Hi Marcel,

On Mon, Feb 27, 2006, Marcel Holtmann wrote:
> 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

[-- Attachment #2: dbus-test.patch --]
[-- Type: text/plain, Size: 2568 bytes --]

Index: hcid/dbus-test
===================================================================
RCS file: /cvsroot/bluez/utils/hcid/dbus-test,v
retrieving revision 1.13
diff -u -r1.13 dbus-test
--- hcid/dbus-test	26 Feb 2006 17:15:48 -0000	1.13
+++ hcid/dbus-test	27 Feb 2006 08:53:31 -0000
@@ -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)

[-- Attachment #3: dbus-name.patch --]
[-- Type: text/plain, Size: 523 bytes --]

Index: hcid/dbus.c
===================================================================
RCS file: /cvsroot/bluez/utils/hcid/dbus.c,v
retrieving revision 1.78
diff -u -r1.78 dbus.c
--- hcid/dbus.c	26 Feb 2006 16:24:07 -0000	1.78
+++ hcid/dbus.c	27 Feb 2006 08:53:32 -0000
@@ -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;

Re: [Bluez-devel] Big rename for the D-Bus API

[Marcel Holtmann]

Hi Johan,

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

> 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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel