← Back to team overview

ubuntu-phone team mailing list archive

Re: Sharing dynamic informations between the user session and the greeter

 

On Thu, 2014-03-06 at 14:34 -0500, Ryan Lortie wrote:

>  - 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.



So we handle this today, with the current indicator-sound patches. First
when ever data is written to the account service a timestamp is also
written. The data is considered invalid if the data timestamp is too
old, that timestamp is kept up-to-date with a timer. The logout
situation is actually more clean than you think, in that when you logout
the player stops playing, we handle it like any other time the player
stops playing and update the information in account service.

Another thing that we can do, that we're not today, is check with logind
to see if the account's session is active and only show data if the
session is logged in. In that case we can assume the data is stale.


> 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.



This is currently handled by the session-manager (in 14.04 Unity,
Upstart) which will restart it. If we're concerned that a restart
shouldn't be possible I think we should at a post-stop stanza to the
appropriate Upstart jobs to clear the data. That seems like an edge case
that probably isn't worth running a post stop for though.

Ted

Attachment: signature.asc
Description: This is a digitally signed message part


References