summaryrefslogtreecommitdiff
path: root/libnm/libnm.ver
diff options
context:
space:
mode:
authorThomas Haller <thaller@redhat.com>2018-12-20 07:48:31 +0100
committerThomas Haller <thaller@redhat.com>2019-01-14 11:56:18 +0100
commitfbb038af5e5d675c994de26da676edfd8e73ffbe (patch)
treee21dbecc633aee31ca5f44e94d31bca5756a6503 /libnm/libnm.ver
parent3ae5c9d595c45b9253b9f1a2c3f56ebd2c9fb1d2 (diff)
downloadNetworkManager-fbb038af5e5d675c994de26da676edfd8e73ffbe.tar.gz
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
Diffstat (limited to 'libnm/libnm.ver')
-rw-r--r--libnm/libnm.ver4
1 files changed, 2 insertions, 2 deletions
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;