Re: [gdm-list] GObject branch

[Brian Cameron <Brian Cameron Sun COM>]

William:

I haven't yet had time to review the code yet, but I wanted to let you
know "Great job".   I think your work lately to revamp GDM is really
a big step forward for GDM.

Do you think this work will be done in the 2.19 cycle or do you
think this will take longer than that?

Some comments:

> Just a quick update on the status of the GObject branch [1] [2].
>
> * D-Bus is now required

I would like to see a list of new libraries that this makes GDM import.
Are we comfortable with all these dependencies being used by a login
program?  Also, what possible security issues are created by making
GDM depend on D-Bus?

> * The class design should be pretty much set.  It seems to work fairly well.
> * The slave process management seems to work well.

We're you able to fix the long-standing and serious issue with GDM
signal handlers not being re-enterant with this work?

  http://bugzilla.gnome.org/show_bug.cgi?id=336549

> * There is another reworking of the configuration framework.  It still
> uses the same desktop file backend.  It is mostly done except for the
> change notification stuff.  The new system works a bit like GConf
> except the backend only knows strings - all typing and interpretation
> of schemas occurs in the client.

I'm prepared for the introduction of lots of bugs.  Every time we revamp
the configuration system, it seems that a lot of new bugs need to be
worked through.

> * Simplified the XDMCP management even more by abstracting all address
> details (GdmAddress).
> * Reworked the md5 and cookie code.

Sounds nice.

> * Added a new generic posix signal handling singleton.
> * The SUP and SOP socket protocols have been removed in favor of the
> separate configuration framework and the D-Bus object API.
> * At least for now I've removed gdmsetup/gdmlogin/gdmphotosetup/gdmdynamic

Note that gdmlogin is needed for accessibility unless we are also
planning on making gdmgreeter work 100% with accessibility.  It is a
long-term goal of mine to get this working, but it will likely take
a lot of work.  I don't think we are ready to get rid of gdmlogin yet.

As mentioned by the SunRay team, I hope gdmdynamic gets put back in
soon.

What about gdmsetup?  I don't really care much about gdmphotosetup,
though some other users might.

> * I don't think I'm going to continue to read the server
> configurations from the configuration file but rather talk to HAL or
> PolicyKit to determine what seats are available.  We should
> dynamically create a display/greeter per seat.  XDMCP works as before.

Will this work in a way such that gdmdynamic can add/delete new ones
as needed?

> At this point I've gotten the greeter to start on both static and
> xdmcp displays.  But since the greeter control protocol isn't hooked
> up logins aren't possible yet.
>
> Next steps:
> * Add caching and bulk retrieval to settings framework
> * Rework the greeter control protocol.
> * Hook the verify framework back up.
> * Make it work.
>
> Ray, I'd like to hear your thoughts on how to redesign the greeter
> control and verify subsystems in light of your smartcard/threaded
> work.
>
> Still kinda in pieces but coming together.  Let me know what you think.

Brian