On Fri, 2014-09-26 at 10:32 +0100, Mathieu Trudel-Lapierre wrote: > On Mon, Sep 22, 2014 at 5:21 PM, Thomas Haller <thal...@redhat.com> wrote: > [...] > > > > the value priv->last_seen (together with nm_access_point_get_last_seen() > > and nm_ap_set_last_seen()) are time stamps as returned by > > nm_utils_get_monotonic_timestamp_s(). > > > > Exposing these absolute values (without a reference point) to another > > process is meaningless. > > I disagree, maybe it's not meaningful to compare directly to boot > time; but it's sufficient to compare values between themselves to > figure out which networks are the newest. > > That's currently what we're mostly interested in. I'm not sure if > there would be other use cases; but the idea is especially to provide > a way for applications to sort accesspoints by age and avoid using > those that have been in scan results before, but not necessarily old > enough or disappeared to be culled from the scan list just yet. > > > > > > > Options: > > > > > > 1) expose the timestamps to absolute times in seconds since 1970 (posix > > time). Note that gint (with 32bit) is to short to represent that > > property. > > > > Downside: timestamps are all wrong in case of resetting the clock. > > As a note, I actually ported this patch to NM master, but it really > has been tested on 0.9.8.8. I think we're at the point here where what > happens is that the timestamps on 0.9.8.8 are actually still retrieved > via time(NULL) initially, so this is basically what was achieved. > > > > 2) expose time stamps to clock_gettime(CLOCK_BOOTTIME) or > > clock_gettime(CLOCK_MONOTONIC). > > > > Downside: timestamps are only meaningful on the very same host. Its > > quite uncommon to expose DBUS over the network, but I think we don't > > want to restrict that. > > > > CLOCK_MONOTONIC is more commonly known then CLOCK_BOOTTIME, but has the > > additional downside of being wrong after hibernate. > > FWIW, I vote for this solution (CLOCK_BOOTTIME specifically); it seems > an acceptable compromise that the values are only meaningful on the > host, since the list of accesspoints is also going to be only > meaningful on that host -- another might not see some, etc. > > [...] > > > Also note that priv->last_seen==0 means "never seen". Both for 1) and 2) > > above, 0 can represent a valid value. > > > > Arguably for 1), We could define that 0 (1970-01-01T00:00:00) means > > "never seen". > > But maybe it would be better to map "never seen" to -1 -- thinking of > > booting up a machine with drained CMOS battery that forgot the time > > stamp and starts ticking at posix-time 0. > > With CLOCK_BOOTTIME, wouldn't 0 also be a value unlikely enough that > we can consider it "never seen"? Seems to me like even if > NetworkManager started at 0; it's quite unlikely that by the time the > system has gotten to start scanning it would still be at 0. > > > I'll update the patch shortly to fix at least Nathanael's comment re: > the wrong string; while we get to agree on exactly how the values > should display.
Yes, at some point it may be useful to see the scan list over a network, like with Cockpit. So we can't preclude that use-case. Even "since the Epoch" doesn't work, because the host and remote system clocks might not be synchronized. So we should really keep this to arbitrary seconds-based units of some kind. In the end, I think CLOCK_BOOTTIME is probably the best, and we can also provide some kind of WiFi.GetLastSeenNow() method that literally returns the value of CLOCK_GETTIME, which then remote clients could match up with a system clock and cache that difference to determine the actual age of the AP. Thoughts? Dan _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
