On Fri, Jul 23, 2021 at 4:20 AM Szymon Janc <szymon.janc@xxxxxxxxxxx> wrote: > > Hi, > > On Friday, 23 July 2021 09:38:40 CEST Marcel Holtmann wrote: > > > >>>>> What is the intention to split BR/EDR and LE here. You do know > > >>>>> up-front what connection type you are. Trying to figure out from the > > >>>>> error code what connection you have been trying to establish is plain > > >>>>> wrong.>>>> > > >>>> In fact the up-front connection type is not necessarily known. In the > > >>>> case of dual-mode devices, such as Bose QC35, a D-Bus client can issue > > >>>> Connect(), and it depends on the timing of connection request (adv > > >>>> usually arrive first compared to inquiry result), it can be either > > >>>> BR/EDR or LE link being established. Another aspect of this is the > > >>>> metrics collection, where knowing transport can be handy. For > > >>>> instance, we can associate the certain error to particular use cases > > >>>> at application layer, and that can help targeting the bottleneck to > > >>>> tackle. > > >>> > > >>> Then we need to find a different way to convey the transport chosen. > > >>> Doing this by error message is a bad idea.>>> > > >>>>> The description is that you want to know exactly where the connection > > >>>>> failed. And I think that can be established independent from the > > >>>>> transport.>>>> > > >>>> Indeed the intention is to know where it failed exactly. However, as > > >>>> mentioned above, transport information is also an important piece of > > >>>> information to know. > > >>> > > >>> We need to find a different way to inform about which transport failed > > >>> (or better which was chosen in the first place).> > > > I would love to hear your thoughts on an alternative. Many of the > > > Apis are transport agnostic (Connect/Pair may end up connecting to > > > either available transports for dual mode devices), but yet the error > > > that results from them are not. Errors from one transport doesn't > > > make sense for one and vice versa. A platform wanting to leverage > > > telemetry and metrics to drive ecosystem improvements would ultimately > > > need to know the difference even if the applications may not need to > > > care. > > > > and we might have made a mistake in the API design and should have given the > > caller more control. We need to review the API design and see if things > > have to change. Just glueing things on at the end makes me suspicious. > > Some (5, wow!) years back I've loosely proposed split for org.bluez.Device API > that was meant to handle some of the dual mode devices issues we've been > seeing [1] [2]. > > We never got time to fully implement it (mostly due to hacking around device.c > instead of properly splitting internal implementation into device_le.c and > device_bredr.c) but got some very initial PoC running. > > With new interfaces old Device1 could be simply super-set of two for legacy > applications purposes. > > Maybe such approach is worth re-considering? > > > [1] https://marc.info/?l=linux-bluetooth&m=145710680912268&w=2 > [2] https://marc.info/?l=linux-bluetooth&m=145973293118003&w=2 Definitely worth reconsidering. We've recently introduced a ConnectLE Api as a stop gap measure for something very similar. I'd love to see the equivalent of a ConnectClassic / ConnectLE distinction. However, I still believe the "Generic" Connect serves its purpose as you alluded to above. Even if it could be built using layers, I still believe there is value from a telemetry POV to understand the errors from the field better and there, the distinction between the specific transport matter. Just like today, I suspect many applications will continue to use the generic "Connect" as to not replicate the logic it ultimately implements for dealing with dual mode devices, yet results/metrics would be important. The team strives to improve interoperability at a large scale in the ecosystem, I believe these data point distinctions are a critical enabler to get better insights into the specific errors customers are seeing. A counter proposal that would be acceptable to you, achieves the objectives and that the team can implement would be a nice next step. Thanks! Alain > > > -- > pozdrawiam > Szymon Janc > >
