Marcel,
Thanks for the quick response; I do appreciate it and the effort all of you have expended in marshaling this migration to DBus. I
fully appreciate the benefits!
I also appreciate that prepending every path with "/org/bluez" was more than a little redundant...
So, under 4.X: the Manager's path is "/";
the Adapter's path is "/hci<n>";
the device's path is "/hci<n>/dev_<remote address>"
Still, the audio device paths will be /org/bluez/device<n>, correct? Or will it just be /device<n>, or perhaps /hci<n>/device<n>?
Also, the old paths are documented in doc/xxx-api.txt. I will be happy to provide updates.
I will also proceed to dig through the code to straighten out the naming per the new names (assuming "experimental" is set).
One more issue: in manager.c and adapter.c, the _init functions enable the new Methods and Signals if experimental is set, then
enables the old Methods and Signals (even if they have the same names) after that.
If experimental is set, should we not turn off the old methods and signals? If you refer to my previous posts, you will find that
when Discovery is completed, signals are returned against the old and new paths/signals simultaneously; very confusing, but now that
I see how things work, I understand why it has been happening.
DS
----- Original Message -----
From: "Marcel Holtmann" <[email protected]>
To: "David Stockwell" <[email protected]>
Cc: "Johan Hedberg" <[email protected]>; "BlueZ development" <[email protected]>
Sent: Wednesday, May 21, 2008 6:41 PM
Subject: Re: Issues with BlueZ v3.31 Object Path Naming
Hi David,
> I have not been chiming in for several weeks, because I have been
> busy hacking through code to figure out how bluez is supposed to
> work, how it actually works, and issues and incompatibilitites I am
> struggling with between bluez (DBus, v3.31) and the CSR BlueLab
> libraries (v4.0, compatible with BT2.1).; What fun.
>
> In working with my test application, talking with bluez, I have run
> into the following and need clarification before proceeding:
> ? What is the path name for the top level Manager interface? Is it
> going to be "/org/bluez"? Or is it supposed to be "/"?
> If you call the DefaultAdapter method with the "/org/bluez" path, it
> is resolved to call old_default_adapter in hcid/manager.c, returning
> a String representing the old Default Adapter path, or "/org/bluez/
> hci0"?
>
> On the other hand, call the DefaultAdapter method with the "/" path,
> it is resolved to call default_adapter in hcid/manager.c, returning
> an Object (actually a string representing an object path),
> representing the NEW Default Adapter path: "/hci0". However, when
> returning the Object, it also throws an error because, somehow, /
> hci0 was never registered. (Unregistered object at path '/hci0').
> Very bad result.
>
> So, what should it be? /org/bluez and /org/bluez/hci0? Or / and /
> hci0?
>
> And, while we are at it, should we clean up the documentation in
> docs/manager-api.txt and docs/adapter-api.txt? Both refer to the
> "old" paths. Let me know and I will be happy to "dive in".
>
> ? For what it is worth, the "new" and experimental Adapter methods
> ARE registered with path "/hci0", despite the apparent fact that no
> object '/hci0' is registered...
> ? I had been confused about opening an audio.Control device as
> opposed to (or in addition to, or in sequence with) a device under
> org.bluez.Adapter, using CreateDevice and CreatePairedDevice. When
> I did get things to "work", sort of, CreateDevice would return a
> device path name like "/hci0/dev_xx_xx_xx_xx_xx_xx", but on return
> would fail with the same "Unregistered object at path" error as above.
> ? Along the lines of the last item, it does appear that one must
> pair, then one must create an audio "device" using the
> org.bluez.audio.Manager CreateDevice method (with path /org/bluez/
> audio). Am I correct in this understanding?
> ? Yet another question: is the "/org/bluez/audio" path correct, or
> will it be changed in the future? When I have used this method, it
> returns a device path of "/org/bluez/audio/device0". It is
> interesting (and perhaps a bit strange) to use the device address,
> as opposed to the device path, to create this pseudo-device to
> provide the audio services (Device, Headset, Gateway, Sink, Source,
> Control).
> I can quickly submit patches to unify the naming, etc., if you will
> tell me your current thinking and roadmap in this area. However, I
> do not want to waste my time hacking if you are going in some other
> direction.
the new object paths are all intentional. We currently support the 3.x
and 4.x API. Once we created 4.0, the old API will go away..
And dbus-api.txt is the 3.x API while doc/*-api.txt is the 4.x API.
Regards
Marcel
Hi David,
> Thanks for the quick response; I do appreciate it and the effort all
> of you have expended in marshaling this migration to DBus. I
> fully appreciate the benefits!
>
> I also appreciate that prepending every path with "/org/bluez" was
> more than a little redundant...
> So, under 4.X: the Manager's path is "/";
> the Adapter's path is "/hci<n>";
> the device's path is "/hci<n>/dev_<remote address>"
that is correct.
> Still, the audio device paths will be /org/bluez/device<n>,
> correct? Or will it just be /device<n>, or perhaps /hci<n>/device<n>?
We are going to re-design that part of the API during the next week.
Once that is done, they will also be deprecated. The idea here is that
we have a generic remote device object path now and we will use it for
every service instead of having every service to do this all over again.
> Also, the old paths are documented in doc/xxx-api.txt. I will be
> happy to provide updates.
I that is so, then that is a bug on my side. It shouldn't be. At least
not intentionally :)
> I will also proceed to dig through the code to straighten out the
> naming per the new names (assuming "experimental" is set).
>
> One more issue: in manager.c and adapter.c, the _init functions
> enable the new Methods and Signals if experimental is set, then
> enables the old Methods and Signals (even if they have the same
> names) after that.
>
> If experimental is set, should we not turn off the old methods and
> signals? If you refer to my previous posts, you will find that
> when Discovery is completed, signals are returned against the old
> and new paths/signals simultaneously; very confusing, but now that
> I see how things work, I understand why it has been happening.
We can't break the old API during the 3.x releases. So the new one can
be enabled for testing. Disabling the old one at the same time will
break to many applications.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel