From fbb038af5e5d675c994de26da676edfd8e73ffbe Mon Sep 17 00:00:00 2001 From: Thomas Haller Date: Thu, 20 Dec 2018 07:48:31 +0100 Subject: all: return output dictionary from "AddAndActivate2" Add a "a{sv}" output argument to "AddAndActivate2" D-Bus API. "AddAndActivate2" replaces "AddAndActivate" with more options. It also has a dictionary argument to be forward compatible so that we hopefully won't need an "AddAndActivate3". However, it lacked a similar output dictionary. Add it for future extensibility. I think this is really to workaround a shortcoming of D-Bus, which does provide strong typing and type information about its API, but does not allow to extend an existing API in a backward compatible manner. So we either resort to Method(), Method2(), Method3() variants, or a catch-all variant with a generic "a{sv}" input/output argument. In libnm, rename "nm_client_add_and_activate_connection_options()" to "nm_client_add_and_activate_connection2()". I think libnm API should have an obvious correspondence with D-Bus API. Or stated differently, if "AddAndActivateOptions" would be a better name, then the D-Bus API should be renamed. We should prefer one name over the other, but regardless of which is preferred, the naming for D-Bus and libnm API should correspond. In this case, I do think that AddAndActivate2() is a better name than AddAndActivateOptions(). Hence I rename the libnm API. Also, unless necessary, let libnm still call "AddAndActivate" instead of "AddAndActivate2". Our backward compatibility works the way that libnm requires a server version at least as new as itself. As such, libnm theoretically could assume that server version is new enough to support "AddAndActivate2" and could always use the more powerful variant. However, we don't need to break compatibility intentionally and for little gain. Here, it's easy to let libnm also handle old server API, by continuing to use "AddAndActivate" for nm_client_add_and_activate_connection(). Note that during package update, we don't restart the currently running NetworkManager instance. In such a scenario, it can easily happen that nmcli/libnm is newer than the server version. Let's try a bit harder to not break that. Changes as discussed in [1]. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/37#note_79876 --- libnm/libnm.ver | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'libnm/libnm.ver') diff --git a/libnm/libnm.ver b/libnm/libnm.ver index f1f6954e53..652e01eb68 100644 --- a/libnm/libnm.ver +++ b/libnm/libnm.ver @@ -1447,8 +1447,8 @@ global: libnm_1_16_0 { global: - nm_client_add_and_activate_connection_options; - nm_client_add_and_activate_connection_options_finish; + nm_client_add_and_activate_connection2; + nm_client_add_and_activate_connection2_finish; nm_device_get_connectivity; nm_team_link_watcher_get_vlanid; nm_team_link_watcher_new_arp_ping2; -- cgit v1.2.1