[Bluez-devel] Moving towards a new API for BlueZ 4.0

[Bluez-devel] Moving towards a new API for BlueZ 4.0

[Marcel Holtmann]

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

Re: [Bluez-devel] Moving towards a new API for BlueZ 4.0

[Manuel Naranjo]

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

Re: [Bluez-devel] Moving towards a new API for BlueZ 4.0

[Marcel Holtmann]

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

Re: [Bluez-devel] Moving towards a new API for BlueZ 4.0

[Manuel Naranjo]

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

Re: [Bluez-devel] Moving towards a new API for BlueZ 4.0

[Marcel Holtmann]

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

Re: [Bluez-devel] Moving towards a new API for BlueZ 4.0

[Manuel Naranjo]

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

Re: [Bluez-devel] Moving towards a new API for BlueZ 4.0

[Robert Rawlins]

[-- Attachment #1.1: Type: text/plain, Size: 1587 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 1869 bytes --]

[-- Attachment #2: Type: text/plain, Size: 228 bytes --]

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

[-- Attachment #3: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Moving towards a new API for BlueZ 4.0

[David Stockwell]

Marcel,

Thanks for all of the great effort, especially in moving toward the DBus model.

I am currently going through the work done to date in audio/control.c (the implementation of AVRCP), and am trying to apply that to 
an application connecting with an AVRCP on CSR's BlueLab 4.0 framework (implements BT2.1+).  I have some ideas, although I am still 
making sure I understand what has been done to this point, and would like to participate in further development (although I am not 
the best C developer).

As things stand, it appears we could use more functions and callbacks to support UnitInfo, SubUnitInfo, Passthrough, and 
VendorDependent (wherein Metadata resides), etc., and at the same time, I think we should not constrain the use cases to the simple 
10-button remote that has been implemented to date.

At any rate, I would like to get involved, as I have immediate interest in moving this forward.  I do have the official Bluetooth 
specs and the CSR IDE, so I think I could contribute from that front.

Any interest?  Who should I communicate with?

David Stockwell


----- Original Message ----- 
From: "Marcel Holtmann" <marcel@holtmann.org>
To: "BlueZ development" <bluez-devel@lists.sourceforge.net>
Sent: Thursday, March 13, 2008 3:32 PM
Subject: [Bluez-devel] Moving towards a new API for BlueZ 4.0


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

Re: [Bluez-devel] Moving towards a new API for BlueZ 4.0

[Marcel Holtmann]

Hi David,

> Thanks for all of the great effort, especially in moving toward the DBus model.
> 
> I am currently going through the work done to date in audio/control.c (the implementation of AVRCP), and am trying to apply that to 
> an application connecting with an AVRCP on CSR's BlueLab 4.0 framework (implements BT2.1+).  I have some ideas, although I am still 
> making sure I understand what has been done to this point, and would like to participate in further development (although I am not 
> the best C developer).
> 
> As things stand, it appears we could use more functions and callbacks to support UnitInfo, SubUnitInfo, Passthrough, and 
> VendorDependent (wherein Metadata resides), etc., and at the same time, I think we should not constrain the use cases to the simple 
> 10-button remote that has been implemented to date.
> 
> At any rate, I would like to get involved, as I have immediate interest in moving this forward.  I do have the official Bluetooth 
> specs and the CSR IDE, so I think I could contribute from that front.
> 
> Any interest?  Who should I communicate with?

go ahead and do so. Patches are always welcome. However, please start a
new thread for it.

Regards



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

Re: [Bluez-devel] Moving towards a new API for BlueZ 4.0

[Johan Hedberg]

Hi David,

On Mar 19, 2008, at 20:04, David Stockwell wrote:
>
> Any interest?

Sure. The current code (mostly written by me) is something rather  
quickly put together to get the basic functionality in place.  
Especially the metadata transfer would be nice to get implemented  
since it's a mandatory feature for category 1 (player/recorder)  
devices in version 1.3 of the specification.

> Who should I communicate with?

In addition this list (as Marcel already mentioned) a good place to be  
in contact with the developers is the #bluez channel on  
irc.freenode.net.

Johan

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