Hi Sorry was too busy so far to catch up reading with this thread.
On Tuesday 26 January 2016 22:07:18 Samuli Seppänen wrote: > One question, primarily to Heiko... does the interactive service solve > the use-case where the administrator/user wants to have persistent > connections that come up on boot and are not closed or managed in any > way in the meantime? In this use-case no user interaction is wanted, > needed or expected. As Gert put it correctly, the interactive service is just an addon service for the interactive use case (currently a GUI). However if I understood you guys correctly the main feature of the other new service (v2) is that it works with Windows 10 and that you can select which connections you start/stop. Well that same thing could be achieved with the interactive service. All you'd need is a little helper program that starts/stops a connection talking to the interactive service. Mainly the parts of the GUI that tell the iservice to start a connection. The service itself is spawning a thread for every openvpn tunnel it is signaled to start. I said it could be achieved, because the iservice currently doesn't handle restarts of openvpn. Instead it trusts the GUI to do so if it expects the connection to be up when a openvpn process disappears. One benefit would obviously be the shared code base and that openvpn could be run under an unprivileged account as well. If it makes sense to extend the iservice to handle the automatic use case is a different thing, who will do it yet another one on top. Someone made the point that the automatic service is a corner use case, most ppl will not use it. I agree. Ppl. used it to overcome the routing issue since Vista, but it was never there for this use case anyway and the interactive service solves this problem. So, having the "automatic"/"v2" service as a completely separate service or even project is fine with me. It just has some consequences that have been mentioned already. If you're all fine with these let's do it. Heiko
