After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 740140 - deal with naive clients failing to recognize new properties
deal with naive clients failing to recognize new properties
Status: RESOLVED FIXED
Product: NetworkManager
Classification: Platform
Component: API
git master
Other Linux
: Normal normal
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks: nm-1.0
 
 
Reported: 2014-11-14 20:28 UTC by Dan Winship
Modified: 2014-11-15 14:54 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Dan Winship 2014-11-14 20:28:07 UTC 
As discussed on IRC yesterday, we have a problem where non-libnm-based clients might do something like:

  settings = conn.GetSettings()
  settings['ipv4']['addresses'].push(myNewIPAddress)
  conn.Update(settings)

which currently would end up having no effect, because the 'address-data' element in settings will take precedence over 'addresses'.

The danw/compat-props-bgoXXXXXX branch fixes this by making the (libnm) client side not send the legacy properties, and making the daemon side prefer the legacy properties to the new ones if both are set (under the assumption that any client sending both of them doesn't realize that it's sending redundant data).

(We had talked before about having the client set some 'yes-i-actually-meant-to-send-address-data' property, but it seemed wrong to force clients to have to jump through an extra hoop if they want to use the preferred properties.)


(This also ends up highlighting a bit of weirdness in NMSettingIPConfig where the :addresses property sort of represents the "addresses" D-Bus property and sort of represents the "address-data" property. I need to fix that better at some point.)
Comment 1 Dan Williams 2014-11-14 23:14:34 UTC 
The branch looks good to me, but I think we should add some code-doc to the legacy NMSetting properties that say that for backwards compat, the legacy properties are preferred if both are sent.  Clients that wish to use '*-data' should not send the legacy properties at all.
Comment 2 Dan Winship 2014-11-15 14:54:15 UTC 
(In reply to comment #1)
> The branch looks good to me, but I think we should add some code-doc to the
> legacy NMSetting properties that say that for backwards compat, the legacy
> properties are preferred if both are sent.  Clients that wish to use '*-data'
> should not send the legacy properties at all.

Well, at the moment we're not documenting address-data and route-data at all, since the docs are still generated from libnm-util. It's on my todo list...