Hi All, Thanks Alain and Szymon for chiming in. Doing a through-out API revamp is definitely worth considering. However, I'd like to point out the fact that these error messages will likely be applicable even after API revamp, since the majority of the error codes are based on errno returned by the kernel. Another comment was on the format of error return. I'd like to hear your feedback on how we present errors in D-Bus return. The two options that we have on the table is (1) string form of error description (2) string form of uint16 error code. (1) is more extendable while (2) is easier to be processed by the client. Regards, Miao On Fri, Jul 23, 2021 at 6:20 AM Alain Michaud <alainmichaud@xxxxxxxxxx> wrote: > > 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 > > > >
