On 30.09.2017 14:34, Tanu Kaskinen wrote: > On Fri, 2017-09-29 at 22:32 +0200, Georg Chini wrote: >> On 29.09.2017 16:03, Tanu Kaskinen wrote: >>> On Sat, 2017-08-19 at 17:48 +0200, Georg Chini wrote: >>>> --- >>>> man/pactl.1.xml.in | 6 +++++ >>>> man/pulse-cli-syntax.5.xml.in | 6 +++++ >>>> shell-completion/bash/pulseaudio | 5 +++-- >>>> shell-completion/zsh/_pulseaudio | 2 ++ >>>> src/pulsecore/cli-command.c | 47 ++++++++++++++++++++++++++++++++++++++++ >>>> src/utils/pacmd.c | 1 + >>>> src/utils/pactl.c | 39 ++++++++++++++++++++++++++++++++- >>>> 7 files changed, 103 insertions(+), 3 deletions(-) >>>> >>>> diff --git a/man/pactl.1.xml.in b/man/pactl.1.xml.in >>>> index 39569b6b..e868babc 100644 >>>> --- a/man/pactl.1.xml.in >>>> +++ b/man/pactl.1.xml.in >>>> @@ -246,6 +246,12 @@ License along with PulseAudio; if not, see <http://www.gnu.org/licenses/>. >>>> </p></optdesc> </option> >>>> >>>> <option> >>>> + <p><opt>send-message</opt> <arg>RECIPIENT</arg> <arg>MESSAGE</arg> <arg>MESSAGE_PARAMETERS</arg></p> >>>> + <optdesc><p>Send a message string to the specified recipient object. If applicable an additional string containing >>>> + message parameters can be specified. A string is returned as a response to the message.</p></optdesc> >>>> + </option> >>> Are the message parameters expected to be just one string? I think it >>> would be more user-frienly to allow the parameters to be split in >>> multiple command line arguments. >> I don't understand what you mean. If you want to pass multiple parameters >> you can do so with one string "param1=xyz param2=abc". In the end, the >> message handler only receives one string and I do not see much difference >> if you have to put the parameters in quotes or not. > I think it's a significant difference in usability. Not a huge one, but > still. We don't require quoting module parameter lists either, even > though they're sent as a single string to the server. This only works because there are restrictions. Something like param="xyz abc" for example cannot be given that way, or only as param="\"xyz abc\"". And there may be other cases which need to be treated separately. If you have a single string, you still need to escape the quotes in the example above but at least it is more obvious why. > >> Using one string leaves >> you free to choose a separator between the parameters and it would also be >> some more overhead to put the string together from multiple arguments. > Do you plan to use some other separator than a space? Whatever the > separator is, it should be used consistently rather than each message > using different conventions. > Why? I think each message should use the parameter format which fits best for the purpose of the message. For example if I send a list of strings "," may be a better separator than " ", while "," is not a good idea when dealing with numbers. This is another reason why I would prefer a single string as parameter list. It is the most variable format we can offer and the intelligence to parse the string can lie completely within the message handler. I guess the command-line feature will anyway be more or less used by developers to test out passing parameters to their code. If you still think I should use multiple parameters, I will change it, but for me it introduces unnecessary restrictions and overhead.
