Re: [gdm-list] [RFE] A modular gdm greeter

[Simo Sorce <ssorce redhat com>]

On Fri, 2007-10-05 at 01:24 +0200, Oswald Buddenhagen wrote:
> hi simo,
> 
> On Thu, Oct 04, 2007 at 06:15:27PM -0400, Simo Sorce wrote:
> > [snip]
> >
> omg, so much explaining for something as self-evident as this. :-P
> it's fun to watch you discussing stuff i implemented in kdm ... uhm ...
> 3 years ago. :-P
> of course it's less fun to know that to date only two plugins exist
> (classic and winbind) and people are complaining about the lack of a
> generic plugin. :}
> </smartass>

Good to know, unfortunately I need something like that for GDM :-)

> watching your rants about pam is very amusing, too - it seems every dm
> developer comes to these conclusions sooner or later (i'm sure you want
> to read
> http://websvn.kde.org/trunk/KDE/kdebase/workspace/kdm/TODO?view=markup
> (the "pam sucks" part near the bottom)).

I hope that didn't look like a rant, or I don't want to know what my
rants about PAM (which I keep private for now :-P) looks like in
reality.

> it's just unfortunate that the pam devels still didn't realize that the
> pam architecture is from the early 90's. my attempts at talking to them
> all went down the drain.

Well the more a module is core to a system, the more it is difficult to
change it, as it involves breaking a lot of dependencies or keeping 2
parallel implementations for a long time. So I can't honestly blame PMA
maintainers, and I prefer to give them clearly well thought
requirements. It's a lot more difficult to say no when you can show
exactly what is not working :-)

> regarding the multiple stacks vs. intelligent stack handling i lean
> towards multiple stacks in separate processes, too. it's just waaay less
> hacky.

The problem is synchronizing multiple process I guess, maybe it can be
done separating the GUI from the PAM conversation handling process, and
just exec it when needed? This way I think we don't get into the issue
of talking to multiple process at the same time, the only problem is
handling the added complexity of pipe communication, but that shouldn't
be that bad.

Simo.