bluez-alsa
bluez-alsa copied to clipboard
arkq
Service properties
This code was written as an exercise when I was learning about the dbus iface code. I occasionally find it useful so I decided to share it. There is a lot of code here for possibly little benefit, so if you feel it is not worth the maintenance burden then please just close it - that's OK.
There is a lot of code here for possibly little benefit, so if you feel it is not worth the maintenance burden then please just close it - that's OK.
No, I think it will be fine to have this, there shouldn't be a lot of burden with maintenance. However, I will pull this not as a single commit. Firstly I will have to review it, because there are some things which will have to be changed. The most important thing is the modification of config.enable flags in case of profile register failure. The problem with that is that if there is some issue with BlueZ registration might fail, but later user might restart BlueZ service, and then registration might succeed. With your change, it will not be possible. Silent modification of command line arguments is not OK, IMHO (at least in that case).
Silent modification of command line arguments is not OK
Yes, that makes sense. These "properties" are a mix of "configuration" (invariant, build-time or command-line selections) and "state" (variable runtime values). I should have been more careful to keep the two separate. Profile is an example of both, so I should perhaps have "ConfiguredProfiles" and "AvailableProfiles" as separate properties. I'll have to introduce extra global state to do that - will look into it soon. Perhaps a more consistent naming convention too might help the user distinguish the two types of Property.
FYI: I've just pulled into the master the commit which adds "list-services" command.
I've raised a new PR with just Version and Adapters. I've left this original branch here for reference - if you would like me to rework any of the properties implemented here I will add them as new commits to PR #444
it is better not to clutter API with debug-only properties
I was thinking of this more as "troubleshooting" than "debugging". An issue is raised "X isn't working any more" and sometimes you have to play 20 questions before it becomes clear that X is not enabled in the service. I was thinking it would be nice to be able to say "please post output of bluealsa-cli status to get all this info in one shot.
This proposal looks excellent. I've been meaning to get my head round a set of troubleshooting steps we can go through with users that report 'X isn't working' without subjecting them to arcane d-bus commands. If this makes that easier, then it gets my vote.
I was thinking of this more as "troubleshooting" than "debugging".
Hmm... if troubleshooting is the rationale for this feature, then OK. I will look at this from a different angle :)
This branch is no longer maintained, so I think there is little value in leaving the PR open. Closing.