Hi,
On Sun, Nov 26, 2017 at 1:06 PM, Selva Nair <selva.n...@gmail.com> wrote:
> 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?
Yes, a line of
echo "msg-n"
will have no effect, since it would append an empty string to the
pending message.
>> 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.
I agree with all of your above comments.
As I understand it, all of that quoting is "outside" of the GUI. (That
is, any quote marks that the GUI gets from the management interface
are to be displayed to the user.)
>> (All spaces after the first one that follows "msg" or "msg-n" are
>> considered part of the text,
I meant this to be the critical part that GUIs need to implement, and
your quoting discussion above works for that.
>> 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.
>
Thanks for that pointer, it's probably much easier. And the echo
buffer (100 messages) should be big enough.
>> 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.
How about muting repeated messages? (Keep a copy of the last N
messages and ignore new messages that have the same content, title,
and destination as one of them).
> (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.?
Url encoding would be fine (with your correction to %2C : ). Since
quotation marks are handled outside the GUI, that would be the only
processing of the text that the GUI would need to do, and it's pretty
simple because "%" is < 0x40 and so won't appear inside a Unicode
sequence, so simple binary string operations will work OK.
That assumes "echo" and "push" work with UTF-8. If not, non-ASCII
characters would have to be encoded, too, in which case we might need
to reconsider and figure out how to do that. (t might be easier and/or
better to make "echo" and "push" work with UTF-8.)
Best regards,
Jon
------------------------------------------------------------------------------
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
