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

[Tanu Kaskinen]

On Sun, 2017-10-01 at 20:26 +0200, Georg Chini wrote:
> 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.

You changed my mind. Using a single string should reduce the confusion
about quoting and escaping, and I agree that "pactl send-message" is
not targeted at everyday use, so optimizing for that is not a priority.

I still think the parameter serialization should be standardized rather
than every command inventing its own format, but that's not relevant
for this patch.

-- 
Tanu

https://www.patreon.com/tanuk