On 01/09/16 09:41, Samuli Seppänen wrote: > Il 01/09/2016 07:33, Selva Nair ha scritto: >> >> On Wed, Aug 31, 2016 at 7:19 PM, David Sommerseth >> <open...@sf.lists.topphemmelig.net >> <mailto:open...@sf.lists.topphemmelig.net>> wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 31/08/16 23:25, Selva Nair wrote: >> > Hi, >> > >> > On Wed, Aug 31, 2016 at 4:11 PM, David Sommerseth >> > <open...@sf.lists.topphemmelig.net >> <mailto:open...@sf.lists.topphemmelig.net> >> > <mailto:open...@sf.lists.topphemmelig.net >> <mailto:open...@sf.lists.topphemmelig.net>>> wrote: >> > >> > > It is not being planned to remove the management interface. If >> > > D-Bus works well for everyone on all platforms, then we can disc >> uss >> > > what to do next. But as of now, I have no plans to remove this >> > > part of the code. >> > >> > >> > That's all what I wanted to hear -- as long as the management interfac >> e >> > (MI) is not going anywhere, no need to panic, right? I like the simple >> > design of the current MI that makes it so easy to debug over command >> > line, support on virtually any platform without external libraries etc >> . >> > Even with D-Bus one has to still send messages specific to the >> > application and the UI developer has to learn a few new keywords. Not >> > very different from the current state of affairs unless we have a use >> > case that is not easy to support over the current MI. I have never use >> d >> > D-Bus so no idea of the status of Windows support -- I believe the >> > reference implementation as a windows port, not sure how well maintain >> ed >> > it is. >> >> I noticed that the upstream D-Bus community have embraced the Windows >> port and included all fixes for Windows there. So it is probably >> somewhat better maintained nowadays. But I have not looked where to >> download things. >> >> If I've understood some of the D-Bus docs correctly, it should also be >> possible to use D-Bus without a "master daemon" running too, but that >> needs to be investigated further. >> >> No, no need to panic :) But I think that GUI's may also have some >> advantages of using D-Bus too, such as getting a more instant >> notifications when something goes wrong, or if a user needs to >> re-authenticate. But I am completely open to explore these areas and >> not set things to stone now. >> >> >> My advice, just leave the management-interface alone, at least until a >> real need for a different framework arises . It "ain't broke", so why >> fix it? >> >> The amount of communication we need/have between OpenVPN and UI's is so >> minimal that it shouldn't take more than an hour for a developer to >> "learn" the current management "protocol". Replacing or even augmenting >> it with D-Bus bringing in new dependency and a lot of bloat doesn't make >> much sense; nor does it look worth the time and effort to me.. > The main benefit seems to be easing the management of clients from the > server-side. This could prove useful when managing VPN servers that have > large numbers of clients, for example in the VPN service provider > use-case. Is that the primary use-case you're thinking of, David?
after reading this entire thread I tend to agree with Selva (mostly). Here's my recap/understanding: - there is a desire to update the management interface , in order to more easily manage clients from the server side. Adding functionality using either D-Bus , REST or (god forbid) SOAP will cause extra libraries to be added - more bloat - on the client side, the management interface is used (extensively) by the client GUI to interact with OpenVPN. The client needs to remain as small and light-weight as possible, with as few external dependencies as possible (can you spell 'pkcs11-helper' ?) Thus, here, we have the desire to keep things the way they are, or at the very least, a strong and understandable desire to NOT add any external libraries So, the management interface suffers from schizophrenia: it must allow for full-blown interaction for large-scale server setups and it must be small and light-weight for the client. IMHO these requirements contradict each other. A possible solution would be to have a separate management interface (or at least management interface *protocol*) for client and server. A counter argument would then be to split the client and server code completely , so that all server support is removed from the OpenVPN client, in order to make the client software even more light weight - is that a route we want to take? Therefore I tend to agree with Selva: this is a very messy problem, don't touch unless there's an absolute need to do so. JM2CW, JJK ------------------------------------------------------------------------------ _______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
