[pulseaudio-discuss] [PATCHv2 27/60] bluetooth: Create pa_bluetooth_transport for BlueZ 5 support

[João Paulo Rechi Vita]

On Sun, Aug 18, 2013 at 5:00 AM, Tanu Kaskinen
<tanu.kaskinen at linux.intel.com> wrote:
> On Fri, 2013-08-16 at 18:32 +0300, Tanu Kaskinen wrote:
>> On Tue, 2013-08-13 at 01:54 -0300, jprvita at gmail.com wrote:
>> >  static void device_free(pa_bluetooth_device *d) {
>> > +    unsigned i;
>> > +
>> >      pa_assert(d);
>> >
>> > +    for (i = 0; i < PA_BLUETOOTH_PROFILE_COUNT; i++) {
>> > +        pa_bluetooth_transport *t;
>> > +
>> > +        if (!(t = d->transports[i]))
>> > +            continue;
>> > +
>> > +        d->transports[i] = NULL;
>> > +        transport_state_changed(t, PA_BLUETOOTH_TRANSPORT_STATE_DISCONNECTED);
>> > +        /* TODO: check if there is no risk of calling
>> > +         * transport_connection_changed_cb() when the transport is already freed */
>> > +        pa_bluetooth_transport_free(t);
>>
>> IMO pa_bluetooth_transport_free() should be called by the transport
>> code, because the backend also creates the transport. The backend may
>> need a callback for getting notified about the device going away. Or
>> perhaps there should be pa_bluetooth_transport_kill(), with a kill()
>> callback in the backend. This would be similar to how sink inputs are
>> killed if the sink they're connected to goes away.
>>
>> If the backend is responsible for calling pa_bluetooth_transport_free(),
>> the core should still ensure that t->device is set to NULL and that the
>> transport is removed from discovery->transports (feel free to create
>> pa_bluetooth_transport_unlink() for this purpose, if you want).
>
> I'll add that it would be good to have the bluez transport backend in a
> separate file, so that there would be clear separation with the
> "bluetooth core" code and the transport backends.
>

In my initial idea of the transport backends, the backend
implementation would provide just the acquire and release callbacks,
and optionally some data that would be available for these callbacks.
I think your idea is to follow a more object oriented approach, with a
bigger separation of the transport objects from the bluetooth core. I
agree this is a good approach, but it's not how the whole Bluetooth
support is currently designed, and the current approach serves well
our current needs, including the ofono-hfp backend. I prefer to keep
the design as is for now.

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