Hi Folks,
so we are near to the end-of-lifetime for the BlueZ 3.x series. We will
have only a few release left and the plan is to end it with the magic
number 3.33 in a few weeks.
Everybody is currently working hard at implemented the new features and
API changes for the 4.x series. We will deprecated a big chunk of the
D-Bus API and basically do major simplifications. For a preview you can
check the new doc/ directory in the bluez-utils CVS repository. It
contains documentation for the new manager, adapter, device and agent
interfaces. The real new stuff is the device interface which will
represent paired and known remote device. Also the agent interface
changes a lot to implement what we have learned during the last two
years of D-Bus usage within BlueZ.
Most of the new API is already implemented and will be part of the 3.29
release within the next few days. All new features are marked as
experimental until we reach 4.0 and you have to start hcid with the -x
option to enable them.
Please review the interface APIs and do some early testing.
More to come soon :)
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
Hi Marcel,
> I am not sure. The code to make this all work is so complicated that I > really wanna remove it when we hit 4.0. Ping me again at some point. > For now we are going without allowing discovery without resolving the > name.
I can imagine this must be a difficult decision to be making, I can appreciate that you want to keep the API and its supporting code as clean as possible.
However, I'm going to +1 with Manuel on this one, my business requirements mean that discovery speed is quite important for me, in fact, I would probably say it was 'vital'. I can appreciate from your stand point that many developers working on gnome bluetooth and dealing with a small number of remote devices it might not be such an issue, however, I think that in a commercial or industrial environment when dealing with M2M communications, knowing the name of a device is pretty insignificant compared to the desire to discover devices efficiently.
It would be a shame to see this feature dropped from the 4.0 build as it would likely mean I am unable to upgrade, I'm also quite sure many other developers working in the industrial sector with M2M and suchlike, such as Manuel, would also be forced into using legacy builds of the stack.
On the flip side, all the other changes to the API look EXCELLENT! I'm looking forward to working with it to see exactly how it implements.
Thanks Marcel,
Robert
_________________________________________________________________
Who's friends with who and co-starred in what?
http://www.searchgamesbox.com/celebrityseparation.shtml
Marcel
> the new MacBooks suppose to have Bluetooth 2.1, but in case of
> Extended Inquiry you need the new firmware (old hardware is okay) on
> both sides. Haven't seen any of it in real life so far, but that is
> what their specs say.
>
Yeah me either, and I have some access to firmwares.
> In that specific case you would, but that is not the case we designed
> the API for.
>
I see.
> You get an additional DeviceFound which will then include the Name
> value in the dictionary.
>
Ok perfect, so then scanning with no name resolve makes no sense at all.
> As mentioned above. You get one (at least one) DeviceFound with no
> Name value and a second one with the Name value.
>
And I guess this one will be sended as soon as the old one was sent right?
> I am not sure. The code to make this all work is so complicated that I
> really wanna remove it when we hit 4.0. Ping me again at some point.
> For now we are going without allowing discovery without resolving the
> name.
If this is the case, when we are still getting a callback as soon as the
device is discovered, and then another one with a resolved name it
doesn't harm the kind of applications I talk about.
What I'm most concerned off, and that's why I used no name resolving, is
that name resolving consumes connections, and we only have 7 per dongle.
And in some cases this is a real issue. In the past (well actually now a
days). What I do is first I scan with no name resolving, and then if I
don't know the device I go and ask the name, and then I go and ask for
the sdp records (I know I'm wasting connections and time).
But with this new API it will be even easier. I can't wait to start
getting my hands on it, and helping as much as I can (and my time allows
me). BTW what will happen with the old libbluetooth? I remember reading
some comments from you saying that 4.0 will remove all the hci commands,
will this be the case?
Cheers,
Manuel
-------------------------------------------------------------------------
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
Hi Manuel,
>> With Bluetooth 2.1 and Extended Inquiry this problem
>> goes away anyway since the name will be part of the Inquiry Result.
>> In
>> case of Bluetooth 2.0 or before, you can always cancel the inquiry
>> when you found the device you are looking for. The name resolving
>> will
>> happen in the order of closest device first. So from the UI
>> perspective you will always have a good experience since users are
>> normally interested in the devices around them. So the only drawback
>> is a Bluetooth 1.1 or before host controller. They are quite rare
>> these days and thus we decided to ignore that problem. Once you
>> connect to a remote device we will automatically fetch the name. Also
>> the name is always cached and only retrieved when we have no
>> information about that device.
>>
> Mhh this makes some sense but... Bluetooth 2.1 isn't out there yet
> right? And it will also require a bluetooth 2.1 dongle too right?
> What if I don't want a GUI, I just want to make a non interactive
> application that needs to track devices that passes near me?
> Wouldn't I
> loose time in resolving names?
the new MacBooks suppose to have Bluetooth 2.1, but in case of
Extended Inquiry you need the new firmware (old hardware is okay) on
both sides. Haven't seen any of it in real life so far, but that is
what their specs say.
In that specific case you would, but that is not the case we designed
the API for.
>> Also the DeviceFound has the Bluetooth address as first parameter.
>> This allows a simple D-Bus filter rule to find them quickly and then
>> for example cancel the discovery process. This helps a lot in the
>> case
>> you are looking for a specific device.
>>
> How does this work? In the past if name wasn't know you will firstly
> get
> a DeviceFound call back, and then a DeviceNameUpdated call back. How
> will this work in the future? Will I get one callback as soon as the
> device is found, and another one once the name is resolved, or just
> one
> with name resolved.
You get an additional DeviceFound which will then include the Name
value in the dictionary.
>> We removed the support for functions that seems to be useful when we
>> designed the current API (about two years ago), but were never used
>> within bluez-gnome or the Maemo UI. The goal of the API is to provide
>> methods that are needed to implement a good Bluetooth experience for
>> without having a bloated and rich API.
>>
> What if we don't want to target GUI devices? Suppose you have a device
> in the door that tracks who comes by, and then opens the door
> depending
> on the bluetooth address, each time a new not know device is
> discovered
> it will make my discovery slower. In the case it only gives one
> callback, if you get a callback as soon as the bt address is known.
As mentioned above. You get one (at least one) DeviceFound with no
Name value and a second one with the Name value.
> Is there any chance I can implement resolveName as a property for
> Adapter?
I am not sure. The code to make this all work is so complicated that I
really wanna remove it when we hit 4.0. Ping me again at some point.
For now we are going without allowing discovery without resolving the
name.
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
Marcel,
> With Bluetooth 2.1 and Extended Inquiry this problem
> goes away anyway since the name will be part of the Inquiry Result. In
> case of Bluetooth 2.0 or before, you can always cancel the inquiry
> when you found the device you are looking for. The name resolving will
> happen in the order of closest device first. So from the UI
> perspective you will always have a good experience since users are
> normally interested in the devices around them. So the only drawback
> is a Bluetooth 1.1 or before host controller. They are quite rare
> these days and thus we decided to ignore that problem. Once you
> connect to a remote device we will automatically fetch the name. Also
> the name is always cached and only retrieved when we have no
> information about that device.
>
Mhh this makes some sense but... Bluetooth 2.1 isn't out there yet
right? And it will also require a bluetooth 2.1 dongle too right?
What if I don't want a GUI, I just want to make a non interactive
application that needs to track devices that passes near me? Wouldn't I
loose time in resolving names?
> Also the DeviceFound has the Bluetooth address as first parameter.
> This allows a simple D-Bus filter rule to find them quickly and then
> for example cancel the discovery process. This helps a lot in the case
> you are looking for a specific device.
>
How does this work? In the past if name wasn't know you will firstly get
a DeviceFound call back, and then a DeviceNameUpdated call back. How
will this work in the future? Will I get one callback as soon as the
device is found, and another one once the name is resolved, or just one
with name resolved.
> You might have also seen that we stripped the whole API a lot.
Indeed, it looks quite easier now.
> We removed the support for functions that seems to be useful when we
> designed the current API (about two years ago), but were never used
> within bluez-gnome or the Maemo UI. The goal of the API is to provide
> methods that are needed to implement a good Bluetooth experience for
> without having a bloated and rich API.
>
What if we don't want to target GUI devices? Suppose you have a device
in the door that tracks who comes by, and then opens the door depending
on the bluetooth address, each time a new not know device is discovered
it will make my discovery slower. In the case it only gives one
callback, if you get a callback as soon as the bt address is known.
Is there any chance I can implement resolveName as a property for Adapter?
Cheers,
Manuel
-------------------------------------------------------------------------
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
Hi Manuel,
>> so we are near to the end-of-lifetime for the BlueZ 3.x series. We
>> will
>> have only a few release left and the plan is to end it with the magic
>> number 3.33 in a few weeks.
>>
> Nice :D, finally good work everyone.
>
>> Most of the new API is already implemented and will be part of the
>> 3.29
>> release within the next few days. All new features are marked as
>> experimental until we reach 4.0 and you have to start hcid with the
>> -x
>> option to enable them.
>>
> Cool, will be an existing experience,
>
>> Please review the interface APIs and do some early testing.
>>
> I have a question regarding the APIs, in the past there was a way to
> initiate scanning without name resolving, and I've been through all
> the
> new API and couldn't find it. Is this going to be removed? I had found
> it as a nice feature, specially when you are in a very crowded area
> and
> you want to discover a device from which you know some stuff like the
> bluetooth address beginning.
we found it very useless and it would make the API (and the code) only
more complicated. With Bluetooth 2.1 and Extended Inquiry this problem
goes away anyway since the name will be part of the Inquiry Result. In
case of Bluetooth 2.0 or before, you can always cancel the inquiry
when you found the device you are looking for. The name resolving will
happen in the order of closest device first. So from the UI
perspective you will always have a good experience since users are
normally interested in the devices around them. So the only drawback
is a Bluetooth 1.1 or before host controller. They are quite rare
these days and thus we decided to ignore that problem. Once you
connect to a remote device we will automatically fetch the name. Also
the name is always cached and only retrieved when we have no
information about that device.
Also the DeviceFound has the Bluetooth address as first parameter.
This allows a simple D-Bus filter rule to find them quickly and then
for example cancel the discovery process. This helps a lot in the case
you are looking for a specific device.
You might have also seen that we stripped the whole API a lot. We
removed the support for functions that seems to be useful when we
designed the current API (about two years ago), but were never used
within bluez-gnome or the Maemo UI. The goal of the API is to provide
methods that are needed to implement a good Bluetooth experience for
without having a bloated and rich API.
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
Hello everyone,
> so we are near to the end-of-lifetime for the BlueZ 3.x series. We will
> have only a few release left and the plan is to end it with the magic
> number 3.33 in a few weeks.
>
Nice :D, finally good work everyone.
> Most of the new API is already implemented and will be part of the 3.29
> release within the next few days. All new features are marked as
> experimental until we reach 4.0 and you have to start hcid with the -x
> option to enable them.
>
Cool, will be an existing experience,
> Please review the interface APIs and do some early testing.
>
I have a question regarding the APIs, in the past there was a way to
initiate scanning without name resolving, and I've been through all the
new API and couldn't find it. Is this going to be removed? I had found
it as a nice feature, specially when you are in a very crowded area and
you want to discover a device from which you know some stuff like the
bluetooth address beginning.
Cheers,
Manuel
-------------------------------------------------------------------------
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