[ConsoleKit] [gdm-list] Reworked patch for multi-seat and multi-display support

[Ray Strode]

Hey,

> I am really liking the approach multi-seat support is taking.
> Thanks for your good work.
Thanks, sorry for the slow turn around in reply. I got side tracked by GUADEC,
and some other things.

> Like I said on a previous email I am working on a NX Server. This server
> basically
> stores parameters and manipulates the session using these parameters.
> It has some shortcommings.
>
>  - Seat should contain a seattype.
>     When I add a seat for NX, gdm don't need to connect to this seat
> SessionToAdd signal.
Makes sense to me.  Right now GDM tries to manage every seat, we could
just manage "default" types or something.

>  - The session id should contain the hostname as prefix. I want it for load
> balance.
>     Like LocalhostSession1
The session id is an opaque object path.  I don't think you should try
to parse it.

> About the generic parameters:
>  - A way to set these parameters.
>     NX allows reconnection to a running X server, and it can change the
> parameters.
>     (example: compression, connection link type(speed), shares, others).
Hmm, okay.  I guess a lot of display types would just ignore updates though.
(wouldn't make sense to change DISPLAY or VT or whatever mid session)

>  -  ConsoleKit should not pass every parameter using signal, ssid is enough
> (maybe exec too).
>     GetParameters on the session object is the correct approach.
>     This way we can keep sensitive information.
Makes sense to me.  It adds an extra round trip, but it seems cleaner.
We don't end up emitting a bunch of data to N different clients when
only one is supposed to get it

> I think the session leader approach should be redesigned.
>  - A session leader should listen to one or more seattypes.
>  - Session leader should have a valid dbus service.
>  - Session leader validation should be done using the dbus service owner
> instead
>     of the pid. This means that a session can be closed by the leader not by
> the pid
>     that launched it.
I think I need a little more explanation here.

Let's start with a summary of how things work:

We have a "seat manager" (say gdm) that sits and listens for seats to
get added and then "manages" those new seats.  In the case of GDM,
this means starting initial sessions on the seats with login screens
or whatever.  When the backend process for a particular login screen
starts its session on the seat it becomes a session leader.  Are we on
the same page so far?

So when you say:

>  - A session leader should listen to one or more seattypes.
You mean "seat manager" here instead of "session leader", right?  This
is what you were talking about above when you asked that each seat
gets its own type and GDM manages specific seat types while NX manages
others, yea?  Makes sense to me.

Then you say,
>  - Session leader should have a valid dbus service.
>  - Session leader validation should be done using the dbus service owner
> instead of the pid. This means that a session can be closed by the leader not by
> the pid that launched it.

This I don't understand.  Are you saying that every session should
have a process with a well known name on the system bus? Why?  Or are
you talking about the seat manager again?

--Ray