ubuntu-phone team mailing list archive

[Ryan Lortie <desrt@xxxxxxxx>]

hi,

On Thu, Mar 6, 2014, at 13:42, Thomas Voß wrote:
>   (1.) What means stale here? My assumption here is that any update to
> AS is timestamped.

Taking the media player example into account there are a few situations
that I can imagine that something goes wrong and we see 'stale'
information (for example: we see a song that is not currently playing
presented on the login screen as currently playing).

 - on bootup we see the last song played before last shutdown
  - not likely a problem in any volatile storage situation

 - after the user logs out we see what was playing when they were logged
 in

 - the user is logged in, but something (ie: the helper) has crashed and
 is no longer pushing updates


The last two are the cases I'm concerned about.  The fact that we have
to push data into accountsservice at logout time to say "okay.. no
longer playing a song" just seems weird.  Having to modify
accountsservice to be aware of the login/logout lifecycle and push this
information into the per-user information storage would also be an
expansion in scope that's beyond simply neglecting to save the data to
disk.  This is certainly possible, but not just a simple patch anymore.

We could work around this issue because the greeter would presumably
know when the user has logged out, even if accountsservice doesn't, and
it could ignore the information in accountsservice in this case.  This
becomes a problem when the user logs back in, however, and the old data
is still there.  We can flush the data at login time and hope nobody
sees it before we manage to do so, but ... ya... this is getting ugly
fast.

There is also a concern if the helper crashes or otherwise stops pushing
data while the user is logged in.  accountsservice would not be able to
detect this (unless we add some even more impressive hacks there).  This
"if the helper crashes" concern is particularly problematic if we put it
inside of something like unity-settings-daemon, which I think would
actually otherwise be a pretty reasonable place for it.

>   (2.) In the "lightdm on session-bus"-case we wouldn't experience
> staleness due to lightdm knowing that the user logged out?

Yes.  lightdm could not help but notice that the user logged out because
the D-Bus connection would be lost.

> So why wouldn't we just put a monitoring/infographics component
> outside of the session and hook it up to the session bus? It could
> expose a very limited API to the session with a very small attack
> surface. The greeter then communicates with that component outside of
> the session (via a different API) and we just leverage it as a proxy.
> The greeter knows when the user logs out, so any sort of staleness
> should be accounted for.

I'm not sure what you are proposing here, but it seems that this is
essentially just implementing the accountsservice idea, but in another
process.  The same problems would continue to apply.

Cheers