* [Bluez-devel] Big rename for the D-Bus API @ 2006-02-27 6:39 Marcel Holtmann 2006-02-27 7:38 ` Johan Hedberg 0 siblings, 1 reply; 6+ messages in thread From: Marcel Holtmann @ 2006-02-27 6:39 UTC (permalink / raw) To: bluez-devel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bluez-devel] Big rename for the D-Bus API 2006-02-27 6:39 [Bluez-devel] Big rename for the D-Bus API Marcel Holtmann @ 2006-02-27 7:38 ` Johan Hedberg 2006-02-27 7:48 ` Marcel Holtmann 2006-02-27 8:57 ` Marcel Holtmann 0 siblings, 2 replies; 6+ messages in thread From: Johan Hedberg @ 2006-02-27 7:38 UTC (permalink / raw) To: bluez-devel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bluez-devel] Big rename for the D-Bus API 2006-02-27 7:38 ` Johan Hedberg @ 2006-02-27 7:48 ` Marcel Holtmann 2006-02-27 9:10 ` Johan Hedberg 2006-02-27 8:57 ` Marcel Holtmann 1 sibling, 1 reply; 6+ messages in thread From: Marcel Holtmann @ 2006-02-27 7:48 UTC (permalink / raw) To: bluez-devel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bluez-devel] Big rename for the D-Bus API 2006-02-27 7:48 ` Marcel Holtmann @ 2006-02-27 9:10 ` Johan Hedberg 2006-02-27 9:19 ` Marcel Holtmann 0 siblings, 1 reply; 6+ messages in thread From: Johan Hedberg @ 2006-02-27 9:10 UTC (permalink / raw) To: bluez-devel [-- 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; ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bluez-devel] Big rename for the D-Bus API 2006-02-27 9:10 ` Johan Hedberg @ 2006-02-27 9:19 ` Marcel Holtmann 0 siblings, 0 replies; 6+ messages in thread From: Marcel Holtmann @ 2006-02-27 9:19 UTC (permalink / raw) To: bluez-devel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bluez-devel] Big rename for the D-Bus API 2006-02-27 7:38 ` Johan Hedberg 2006-02-27 7:48 ` Marcel Holtmann @ 2006-02-27 8:57 ` Marcel Holtmann 1 sibling, 0 replies; 6+ messages in thread From: Marcel Holtmann @ 2006-02-27 8:57 UTC (permalink / raw) To: bluez-devel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2006-02-27 9:19 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2006-02-27 6:39 [Bluez-devel] Big rename for the D-Bus API Marcel Holtmann 2006-02-27 7:38 ` Johan Hedberg 2006-02-27 7:48 ` Marcel Holtmann 2006-02-27 9:10 ` Johan Hedberg 2006-02-27 9:19 ` Marcel Holtmann 2006-02-27 8:57 ` Marcel Holtmann
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).