Re: network-manager-openvpn

[Dan Williams <dcbw redhat com>]

On Fri, 2009-09-11 at 04:27 +0200, Luc Deschenaux wrote:
> > > 1. It should be possible to activate simutaneously many openvpn
> > > configurations using checkboxes instead of radiobuttons, (in server mode
> > > also, say in a second time...).
> > 
> > Yes, this is something that's been on the map for a while but there was
> > other stuff that we considered more important.  It will take some rework
> > internally in NetworkManager, though NM 0.7 already has half the work
> > done.
> > 
> > > 2. It should be possible to "import" any openvpn configuration file, eg:
> > 
> > The 0.7 openvpn plugin should already be able to import an openvpn
> > connection, but I think we just never got around to implementing export.
> 
> Every configuration parameter should be importable/modifiable, not only
> the ones used in a given configuration.
> 
> > What specific configuration were you having problems with?  Can you
> > attach that config so we can see what's going on with it?
> 
> My config was attached :) But someone may need to use other parameters
> as well.
>  
> > > * Options not modifiable actually by network-manager-openvpn should also
> > > be gathered and displayed, eg: in a dynamic listbox like for the routes,
> > > with an add button. There could be a pop-up in the first column to set
> > > or change the option name, an editable field in the second column to set
> > > or change its value.
> > 
> 
> > 0.7 already provides the ability to specify custom routes to apply to
> > the connection in addition to any routes sent by the server.
> 
> >  
> Read slowly, im not talking about routes here, talking about all the
> openvpn parameters that are not yet configurable/importable with the
> current graphical interface. They could just be configured through or
> imported into a single listbox as described above.

But that's *horrible* UI and not something I'd like to condone.  I'd
rather add the options on an as-needed basis to ensure we don't just
dump everything in, and find out that we overloaded the UI with 50
options that almost nobody uses.  Which I suspect is true for at least
half of openvpn's options, because they did absolutely no work in
consolidating them and asking the people who requested the options what
they were actually trying to accomplish to constrain the number of
switches that openvpn supports.  I'm interested in making it work for 90
- 95% of use-cases, but I don't think we should be designing for that
last 5%, especially when it makes things nearly unusable for the other
90.

Dan