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 _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
