Hi,
On Sun, Nov 26, 2017 at 10:49 AM, Jonathan K. Bullard <jkbull...@gmail.com>
wrote:
> Hi. (Top posting without quoting because I'm not reacting to specific
> comments.)
>
> I think Selva's approach of separate commands instead of separate
> fields in a single command is better for several reasons and withdraw
> my earlier proposal.
>
Me too :)
>
> How about (1) the ability to append messages to each other, (2) a
> "msg" command which concatenates a newline to the text of a message,
> and (3) a "msg-n " command, which doesn't, and putting the title in
> the command that causes display?
>
This is a very good idea.
>
> I think that would mean there is no need to escape anything or make
> any OpenVPN changes, and it's easy to generate, read, parse, and
> process.
>
> This:
>
> echo "msg This message"
> echo "msg will be shown"
> echo "msg"
> echo "msg on four lines (the third line is empty)."
> echo "msg-window the title"
>
That nicely solves the problem of when to display the message.
One concern about quoting, though: As the most common use of
this will be to push from the server, those quotes will need to be
escaped. So I suggest an improvement:
(i) If/when number of spaces between words is not significant,
quotes are not necessary as the option parser concatenates all
words after echo into one string with a single space between words.
(ii) When space is significant as in your msg-n proposal below, quote
the message excluding the keyword "msg" or "msg-n"
Then the echo command could be specified as
echo msg This message
and its pushed version becomes
push "echo msg This message"
When quoting is required to embed spaces or otherwise
echo msg "This message is stretched "
and
push "echo msg \"This message is stretched \" "
or using single quotes
push "echo msg 'This message is stretched ' "
etc. Quoting the message by itself makes it easier
on the eye, I guess.
Users may still come up with creative ways of quoting as
what eventually gets displayed will be what comes through
the management interface after quote processing by the
parser at the server side for the push, and the client side
for the echo. We need only to carefully specify how the GUI
will interpret the received echo message.
> would display the following in a non-modal popup window with title
> "the title". There is no need for an "OK" button if the window has a
> close button, but that could be implementation-defined behavior.
>
> =============================
> This message
> will be shown
>
> on four lines (the third line is empty).
> =============================
>
>
> And
>
> echo "msg-n this other message"
> echo "msg-n "
>
That could be
echo msg-n ' '
and
push "echo msg-n ' ' "
(or use escaped double quotes). Arguably easier to read and write.
echo "msg-n will all be"
> echo "msg-n"
>
Such lines will have no effect, right?
> echo "msg-n displ"
> echo "msg-n ayed on one line."
> echo "msg-window the title"
>
> which would display:
>
> ==========================================
> this other message will all be displayed on one line.
> ==========================================
>
Sounds good, otherwise.
> (All spaces after the first one that follows "msg" or "msg-n" are
> considered part of the text, so there are lots of spaces between
> "message" and "will", "be" and "displayed" are separated by the second
> space after "msg-n" in "echo "msg-n displayed on one line", and
> "displ" and "ayed" are joined together because there is no such space
> in "msg-n ayed on one line".)
>
>
> What to do about wrapping lines that are too long (whatever that means
> : ) after concatenation would be implementation-defined.
>
>
> To display as a notification instead of a window, the last command
> would be replaced by:
>
> echo "msg-notify the title"
>
>
> To display a URL in a non-modal popup window with contents of URL
> "the_url" and title "this is the title", the sequence could be:
>
> echo "msg the_url"
> echo "msg-url this is the title"
>
> (One use of that would be to show a user _how_ to do something, like
> changing a setting in the GUI, instead of just telling them to do it.)
>
>
> Regarding length limits, I don't think we need to impose any limits
> beyond the limits imposed by OpenVPN. The OpenVPN limitation on the
> length of individual parameters and the limitation(s) of the buffers
> in the management interface are the two limits I know of. A note about
> those would be appropriate wherever these echo commands are documented
> (in the management interface doc, I assume).
>
> Keeping track of "pending" information (such as the text to be
> displayed to the user) must be considered:
>
> A. If a GUI disconnects from the management interface while the
> VPN is still connected and then later reconnects to the management
> interface. (Tunnelblick can do that -- we even let the user quit
> Tunnelblick or log out.) I'll probably have Tunnelblick save and
> restore any pending data in that situation.
>
Sending an "echo all" will retrieve this info (within the limits of the echo
history buffer in openvpn) and that may be enough to recover incomplete
echo messages received prior to connecting to the mgmt i/f.
>
> B. If the VPN disconnects or OpenVPN crashes while there is
> pending information, I think I'd just discard it on the assumption
> that it is incomplete and probably no longer relevant.
>
Agree.
Two issues:
(i) Both SIGUSR1 and SIGHUP restarts will repeat the echo messages.
How to decide whether the UI should show the message again or not?
Repeated messages could become a nuisance pretty fast.
(ii) Though probably not documented, strings containing comma
cannot be pushed from the server as it stands now. Should we support
some form of encoding, say url encoding like %27 for comma etc.?
Selva
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
