[LightDM] Hard dependency on AccountsService

[Yves-Alexis Perez]

On ven., 2011-08-26 at 11:13 +0200, Yves-Alexis Perez wrote:
> On lun., 2011-08-22 at 11:26 +1200, Robert Ancell wrote:
> > On 20 August 2011 02:53, David Edmundson <david at davidedmundson.co.uk> wrote:
> > > Do you have links to anything explaining about AccountsService?
> > > Explaining what it is, why it's better than dealing with files directly,
> > > that sort of thing.
> > > Dave
> > 
> > I talked to Ray Strode who is one of the main developers of
> > AccountsService.  Some relevant quotes:
> > "AcccountsService has always been an ad hoc "serve our needs right
> > now" type thing.  We don't have much documentation about it."
> > "Ideally at some point it would become integrated with or superceded
> > by SSSD at some point in the future." [1]
> > "It's main purpose at the moment is to serve the needs of GNOME, but
> > the kind of thing it's doing is general, so it made sense to keep it
> > on freedesktop so it could get adapted as needed for other desktops if
> > there is interest."
> > 
> > (I think this is an appropriate position to take given the age of the project)
> > 
> > Unfortunately there isn't much I can point you to.  I'll add a Wiki
> > page on freedesktop.org that at least provides a basic overview so
> > there is something to point at.  From my point of view the advantages
> > are:
> > - Puts all behaviour in one place - which means less code in lightdm
> > and less places for bugs
> > - Caching/storing of information done in one place - currently the
> > .dmrc may be unreadable by different users, there needs to be a cache,
> > home directories may not be mounted...
> > - Consistent API - all user accounts features are accessed using
> > D-Bus, so don't have to use glib for some features, open files, run
> > programs for others
> > - Support for new backends - who knows what sorts of account systems
> > we will migrate to in the future (e.g. Facebook logins?), a good API
> > means we don't care
> 
> Oh dear...
> 
> > - Able to modify users using the API - it may make sense to add users
> > from the greeter, so a service like this would make this much easier
> 
> I' not really sure that's something I want.
> 
> > - Easier to test - you can make a mock accounts service easier than
> > faking all the different components of the current system
> > 
> > I think based on this and the feedback received lightdm will
> > definitely continue to support both legacy and accounts service for
> > the near future, but I'd like to hope we can move to an API like this
> > in the future.  So please get this idea on the agendas of the
> > different desktops :)
> 
> Please, KISS. I'm not really sure I like that AccountService stuff if it
> means overengineering things.
> 
> Besides, right now I'm not sure it's really relevant for a cross desktop
> and cross-distro tool. 
> 
> The switch to systems libraries to avoid code duplication is nice, but
> right now it seems that keeping dmrc files as a fallback looks like a
> good idea. (and note that there are other areas where code duplication
> could be dropped, like for Xauthority generation).
> 
I'm not sure if this is a bug or if this was finally settled in favor of
hard dep on accountssercices, but 1.0.0, once provided a
lightdm-autologin pam file (thanks for #863630), still has some huge
timeouts at startup and login time, because it apparently waits on a
dbus reply.

It seems to work just fine without, only a delay, so I guess this is
indeed a bug. If you do confirm it's a bug, I'll make a report on
launchpad. If it's not, then I'm quite disappointed and ask again to
reconsider this.

Regards,
-- 
Yves-Alexis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/lightdm/attachments/20111003/3c8d29ec/attachment.pgp>