On Tue, Aug 20, 2013 at 2:36 AM, Tanu Kaskinen
<tanu.kaskinen at linux.intel.com> wrote:
> 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.
>
Ok, I'll just leave it as is, then.
--
Jo?o Paulo Rechi Vita
http://about.me/jprvita
