[pulseaudio-discuss] [PATCH 00/56] Refactor of BlueZ 5 support

[João Paulo Rechi Vita]

On Tue, Jul 16, 2013 at 6:20 AM, Tanu Kaskinen
<tanu.kaskinen at linux.intel.com> wrote:
> On Sat, 2013-07-13 at 09:06 +0200, Mikel Astiz wrote:
>> Hi João Paulo,
>>
>> On Fri, Jul 12, 2013 at 8:06 PM,  <jprvita at gmail.com> wrote:
>> > From: João Paulo Rechi Vita <jprvita at openbossa.org>
>> >
>> > This series reverts the previous support for BlueZ 5, renames the "bluetooth"
>> > portion of the old modules name for "bluez4", creates a new set of modules for
>> > BlueZ 5 supporting A2DP sink and source roles, and provides configuration
>> > options to independently enable/disable each modules set during build. The
>> > transport acquire/release operations have been reworked to provide a way to
>> > implement this operations in transport backends out of the bluez5 modules core.
>>
>> What's the reason to follow the revert-approach instead of doing a
>> simple split of the existing code? Is it perhaps because the resulting
>> code is very different to the original one?
>>
>> Splitting would be much easier to review instead of starting from scratch.
>
> Indeed. I would have expected João to first create a copy of the file
> set, and then remove bluez 4 functionality from one file set and remove
> bluez 5 functionality from the other file set.
>

The main reason was to make sure that the BlueZ 4 modules are free
from BlueZ 5 code and working in the exact same way as before. But
also because I found easier to write do it this way, since there is
much more code in the BlueZ 5 new modules than the code that was
removed from the BlueZ 4 modules. And at this moment I really don't
want to spend more time to change that, let's try to focus on having
this ready for the next (3.10 IIRC) GNOME release, which the freeze is
August 19th (but we should have the code in master before that, to
allow time for release and downstream testing).

> Another thing (I should have brought this up earlier, but I only
> realized this today): not having a generic module-bluetooth-discover
> breaks old configuration files, which I hate (FWIW, I believe Arun
> doesn't care about breaking configuration compatibility that much, I
> don't know David's opinion). João, would it be too much to ask from you
> to write a stub module-bluetooth-discover, which checks the bluez
> version at runtime and then loads module-bluez4-discover or
> module-bluez5-discover depending on the detected version?
>

It was already agreed before that we would do it this way, and I don't
think we should do a D-Bus roundtrip just to detect the BlueZ version.
Right now we're compiling both modules by default and generating a
default.pa that loads module-bluez4-discovery by default, so IMO it's
already good enough to help packagers do the right thing. I'm not
exactly sure what's the situation you want to improve not breaking
configuration-file compatibility, but one way might make you happy is
if we do not rename module-bluetooth-* to module-bluez4-* at this
moment, and later when we decide to make BlueZ 5 support the default
one we rename module-bluetooth-* to module-bluez4-* and
module-bluez5-* to module-bluetooth-*. This will save us from breaking
configuration files, but at the price of making the codebase a bit
more confusing IMO, which I'm fine with as long as we have a good
rationale for that.

P.S.: I'm on vacations atm and will be in a road trip for the next 8
days, so I'll be with limited access to email and testing devices. But
I'll do my best to read and fix comments to the path series ASAP.

--
João Paulo Rechi Vita
http://about.me/jprvita