Re: [gdm-list] GObject branch

["William Jon McCann" <mccann jhu edu>]

Hi,

On 6/4/07, Brian Cameron <Brian Cameron sun com> wrote:
> 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.

Thank you.

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

That is what I was originally shooting for.  However, at this point it
isn't looking very likely.  Safe bet is to have the branch
functionally complete by the 2.20 release and merge with trunk at the
start of the 2.21 cycle.  This will leave a full release cycle to
shake out bugs.

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

D-Bus is designed to have no additional dependencies and to be
trustworthy/secure.  It is highly qualified for this role.

> > * 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?

Yeah, I think so.  Signal handlers are not used for notification at
all anymore so that basically solves the problem by design.

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

Perhaps.  But the new system has a number advantages here.  For one it
just uses D-Bus as the IPC mechanism so that eliminates a lot of
possible bugs right there.  Also the functionality in the backend is
reduced and made much more modular.  Instead of using a two
configuration files default and custom there is just a schemas
definition and the data store file (gconf-ish).  The schemas
definition is parsed and handed by the client side - so we can use
asserts to enfore the type etc. contracts.  These will make it much
easier to make it correct - and find bugs early and easily.

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

As soon as possible.

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

Some thought needs to go into how to make a better gdmsetup.  Such as
how to leverage PolicyKit, how to best use the new gdm settings api,
etc.

The gdmphotosetup functionality should probably just get merged with
some other tool like gnome-about-me or something...

> > * 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?

Not sure yet but hopefully.  But surely gdmflexiserver will also
benefit from this...

Jon