GNOME Bugzilla – Bug 749951
stabalize NMVpnPlugin API for libnm
Last modified: 2016-01-20 13:38:41 UTC
When introducing libnm (nm-1-0), we renamed NMVpnPlugin to NMVpnPluginOld but did not yet fix the API. Before porting and VPN plugins over to libnm we must stabalize that API. That means, properly implement a new NMVpnPlugin.
first patches are on bug 749877
bug 749877 was merged to master as http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=3e39e5b4f04aa1ad16b226ae687413d02aa5b8eb It deprecates NMVpnPluginOld API and adds NMVpnServicePlugin as new API for 1.2. NMVpnServicePlugin is currently still identical to NMVpnPluginOld (except renaming). Whatever the plans were to improve NMVpnPluginOld API, that should be done before releasing 1.2.
[[Quoting private message from dcbw regarding how to improve the NMVpnPluginOld/NMVpnServicePlugin API]] Multiple VPN connections per service - the API right now only allows one, and there are two options here. First, spawn multiple VPN service daemons per connection. This is probably the simplest option, but requires that we rework the D-Bus communication to use private sockets instead of bus names. That's probably something we should do anyway, since the VPN service daemons don't need to be on the public bus at all. Second option is making each daemon control multiple VPNs in one process. This is the most architecturally clean, I think, but a much larger change internally and to the D-Bus API of the daemons. (or other options I haven't thought of...)
(In reply to Thomas Haller from comment #3) > [[Quoting private message from dcbw regarding how to improve the > NMVpnPluginOld/NMVpnServicePlugin API]] > > > Multiple VPN connections per service - the API right now only allows > one, and there are two options here. > > First, spawn multiple VPN service daemons per connection. This is > probably the simplest option, but requires that we rework the D-Bus > communication to use private sockets instead of bus names. That's > probably something we should do anyway, since the VPN service daemons > don't need to be on the public bus at all. Using a private D-Bus sounds great. We should do that. Note that the NMVpnServicePlugin API is not very large. Supporting multiple VPNs probably only requires minimal changes to that API. > Second option is making each daemon control multiple VPNs in one > process. This is the most architecturally clean, I think, but a much > larger change internally and to the D-Bus API of the daemons. having one daemon control multiple VPNs seems more complex for the daemon. What are the advantages of even doing that? Maybe lower memory-footprint and performance... but that doesn't seem too convincing. The downside is, if the daemon crashes or gets stopped/killed, multiple VPNs go down. Also, extending the D-Bus API might be hard in a back-ward compatible way. Maybe we'd have to create a separate v2 API. Either way: a lot of work. > (or other options I haven't thought of...)
I think this is now done, and also all our VPN plugins migrated to use the new libnm API, which seems to be fine. The multiple-VPN problem was solved by spawning multiple plugin instances. Thus the libnm API didn't change much. Closing BZ.