On Tue, Nov 26, 2024 at 1:19 AM Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: > We got a few options here: > > 1. As separate commands > 2. As extra optional argument to existing commands > 3. As mandatory argument that indicates its type to existing commands > > I think option 2 is the better one if we could skip entering ad with > an empty array e.g: > > advertise.data type "" "srd..." > > Option 3 would break existing scripts since we need to change the > argument positions, but we don't really care about it since now, so I > don't think it would be a problem, but since we have option 2 I guess > that is better in this sense. Option 3 seems somewhat aggressive, in my opinion. From the outset, `bluetoothctl` has not offered commands for scan responses, so I assume these are not crucial for most developers. Therefore, making it a mandatory argument to force all developers to be aware of scan responses seems overly aggressive. Option 2 appears more favorable, but I think that writing two different datasets in one command is a bit complex. I would prefer to set/get two datasets separately: advertise.data type xx xx xx advertise.data srd type yy yy yy advertise.data advertise.data srd Option 1 remains my preferred choice because it seems simpler to me. It also aligns well with the existing `clear` command: advertise.sr-data type yy yy yy advertise.clear sr-data Is there any downside to introducing new commands? The prefix 'sr-' may be hard to understand without reading the documentation, but I haven't found a better abbreviation for 'scan response'. Considering `bluetoothctl` is a command-line tool, I opted for the shortest prefix.
