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 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/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
[email protected]
https://lists.sourceforge.net/lists/listinfo/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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel