[pulseaudio-discuss] [PATCH 3/6] pactl, pacmd, cli-command: Add send-message command

[Georg Chini]

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.