Hi, > > I don't think this is the right approach for OOB data because this > > information may become private to bluetoothd if the device is not > > created since it is not associated with any device object/path, IMO > > the OOB data needs to be passed in the CreateDevice which should take > > a dictionary containing all the known information of the device, but > > that breaks the API otherwise I would already send a patch proposing > > this. > > Right, i'v discussed this approach with Johan and Szymon on freenode > -- i'v changed few things after that (mostly because implementing it > in AddRemoteData would break api, so i moved it to separate method) -- > maybe it would be a good idea to have this functionality now in this > form and change it when the api break would be possible (5.0?)? To me, the closest analogy of receiving data like this over some OOB channel is an inquiry result HCI event. Therefore, it'd be intuitive to have this behave in a similar way: the data goes to storage and triggers a DeviceFound event. Calling Create(Paired)Device remains separate from all this. This doesn't of course mean that we couldn't/shouldn't restructure the device discovery process for 5.x to e.g. have D-Bus objects for every found device and a Device.Pair() method, but the device information received over an OOB channel should still map to a similar set of steps as what happens when receiving a HCI inquiry result event. Johan -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
