[pulseaudio-discuss] [PATCH 42/56] bluetooth: Get BlueZ 5 device object

[João Paulo Rechi Vita]

On Mon, Jul 29, 2013 at 8:53 AM, Tanu Kaskinen
<tanu.kaskinen at linux.intel.com> wrote:
> On Thu, 2013-07-25 at 21:41 -0300, João Paulo Rechi Vita wrote:
>> On Mon, Jul 22, 2013 at 11:56 AM, Tanu Kaskinen
>> <tanu.kaskinen at linux.intel.com> wrote:
>> > If the discovery object was just created, the devices haven't been
>> > enumerated yet, so module-bluez5-device doesn't work without loading
>> > module-bluez5-discover first. This is nothing new - it looks like the
>> > old code did the same thing. I wonder why we even bother to have a
>> > separate device module, if it can't be used without the discovery
>> > module.
>> >
>>
>> Bringing the discussion to where it belongs, as I said on 40/56,
>> manually loading the device module doesn't work anymore. I don't know
>> when it stopped working, but I was never something we cared much
>> about, so perhaps we should explicitly not support manually loading
>> it. Is there a way to enforce this via PulseAudio's module-loading
>> system?
>
> Sorry, I ruined your attempt to have the discussion where it belongs. I
> replied to this in the previous mail.
>
>> IIRC was Lennart's suggestion to have this architecture, back in 2008,
>> which is similar to how module-detect/module-udev-detect loads audio
>> drivers. Even not supporting loading module-bluez5-device without
>> loading module-bluez5-discover, it seems to me that there is a better
>> separation to have one module for each I/O thread and Bluetooth card
>> than having all cards/threads being handled by one module.
>
> In what way is it better? It's entirely possible to keep the code in
> separate files without also having a separate module. I don't personally
> see the benefit of a separate module.
>

I don't think we should change this architecture at this very moment.
Maybe we can get back to this point later on, if we decide the
benefits are worth the work.

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