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

[Tanu Kaskinen]

On Mon, 2013-08-19 at 13:44 -0300, João Paulo Rechi Vita wrote:
> 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.

I don't see how the design of the current Bluetooth support is in any
way in conflict with having proper separation between the core and the
transport backends.

If you think that it's not worth the effort to improve the separation, I
disagree, but I don't care enough to have a lengthy argument about it,
so do as you think is best.

-- 
Tanu