summaryrefslogtreecommitdiff
path: root/introspection
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 /introspection
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 'introspection')
-rw-r--r--introspection/org.freedesktop.NetworkManager.xml3
1 files changed, 3 insertions, 0 deletions
diff --git a/introspection/org.freedesktop.NetworkManager.xml b/introspection/org.freedesktop.NetworkManager.xml
index b8d0b5c125..efd866db47 100644
--- a/introspection/org.freedesktop.NetworkManager.xml
+++ b/introspection/org.freedesktop.NetworkManager.xml
@@ -119,6 +119,8 @@
@options: Further options for the method call.
@path: Object path of the new connection that was just added.
@active_connection: The path of the active connection object representing this active connection.
+ @result: a dictionary of additional output arguments for future extension. Currently not additional
+ output arguments are supported.
Adds a new connection using the given details (if any) as a template
(automatically filling in missing settings with the capabilities of the
@@ -138,6 +140,7 @@
<arg name="options" type="a{sv}" direction="in"/>
<arg name="path" type="o" direction="out"/>
<arg name="active_connection" type="o" direction="out"/>
+ <arg name="result" type="a{sv}" direction="out"/>
</method>
<!--