• Thomas Haller's avatar
    all: return output dictionary from "AddAndActivate2" · fbb038af
    Thomas Haller authored
    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] !37 (comment 79876)
    fbb038af
org.freedesktop.NetworkManager.xml 25 KB