On Fri, 2016-05-27 at 18:11 +0200, Alfonso Sanchez-Beato wrote:
Hi, I have been thinking a bit more about how to expose the device statistics, and I came through two options for this: ** OPTION 1 Looking at current NM DBus interfaces, the natural way of linking an interface with a device would be to add a property to org.freedesktop.NetworkManager.Device which would hold an object path, in a similar way to ActiveConnection or Ip4Config. We could add one called Statistics, which would contain an object path of the form "/org/freedesktop/NetworkManager/Statistics/[N]". That object path would implement the org.freedesktop.NetworkManager.Device.Statistics interface, with properties as discussed in thread [1]. This fits well if the Statistics interface is dynamic, and is removed/recreated each time a connection is closed/established. ** OPTION 2 We can consider the statistics interface non-dynamic (i.e. same life cycle as Device). I actually think this is a better option because in the phone case cellular connections can easily drop and then be re- established, and it would not make sense to reset counters each time that happens (it would be difficult to track data usage). In this case it might make sense to have the interface (org.freedesktop.NetworkManager.Device.Statistics) as a new interface directly implemented by the device object (/org/freedesktop/NetworkManager/Devices/[N])
Hi Alfonso, I think, if some properties are strictly tied to the lifetime of the device, then they should be on the device itself (or on a separate interface on that device). The reason is that it is relatively cumbersome from the D-Bus API to track both device and IP4Config instance, although they always come together. That is, a IP4Config object makes only sense with its device. In hindsight, I think IP4Config gets this wrong. For now, OPTION 2 seems preferable to me. Thomas
Attachment:
signature.asc
Description: This is a digitally signed message part