(Resend in Plain Text) Hi Syzmon > Are we going to add prop for every data type? I only need the advertising flags. The others ones I need are already properties in Bluez.Device On Wed, Oct 19, 2016 at 10:15 AM, Johan Hedberg <johan.hedberg@xxxxxxxxx> wrote: > Hi Luiz, > > On Wed, Oct 19, 2016, Luiz Augusto von Dentz wrote: >> > Hmm I wonder.. why not just expose full AD + SCAN_RSP this way? >> > Are we going to add prop for every data type? >> >> Then there is no reason to parse the AD, and even broken/unknown AD >> should be send which sounds like a very dangerous think to do so Id >> leave this for application that can deal with the management socket >> but not over D-Bus. > > I'm not so sure about this (having a "raw" AD/EIR API). We don't > necessarily need to expose the raw data as such, but it could be a > dictionary where the key is the data type and the value a byte array. > That'd at least prevent common pitfalls with broken parsing. > > We could also consider making this a subscription based thing so that > it's not a broadcast signal but either a unicast signal or a method call > to whomever has requested to receive the information. Side note: I think > the approach the bus1 folks would like to take is to get rid of > broadcast signals completely and rely on a service-based subscription > mechanism. > > 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
