Re: [gdm-list] Making the greeter interface accessible from outside

[Giovanni Campagna <scampa giovanni gmail com>]

2012/5/3 Ray Strode <halfline gmail com>:
> Hi,
>
>> You need a dynamic bus name, because you can have multiple slaves at
>> the same time.
>> I thought of SeatId because session applications have XDG_SEAT in the
>> environment, and because a slave conceptually maps to one login, or
>> seat.
> a slave does match to one login, but it doesn't match to one seat. a seat can
> have multiple logins.  DBus really isn't made for dynamic bus names, anyway.

I don't undersand why this aversion to dynamic bus names. Telepathy
uses them, for instance, and they work well - it's all a matter of
documenting a defined format and ensuring that clients are able to
build them.

> I think a better approach is to talk to the gdm-binary process.  I
> believe it already
> owns the well known name org.gnome.DisplayManager.  3 ways I can think of:
>
> 1) It could have a method like GetSlaveBusName(String session_id) that
> would return the unique name of the appropriate
> slave.
> 2) GetSlaveBusName() with now parameter, and instead gdm-binary would
> then figure out the session id of the caller automatically,
> and return the unique name of the appropriate slave.
> 3) Put the entire applicable interface (i guess it's just one method,
> OpenConversation?) on org.gnome.DisplayManager, and it could
> forward the request to the appropriate slave implicity under the hood.
>
> I think 3 is the nicest from an API point of view.

I don't think any of this belongs to gdm-binary. We already have a
component that supervises login sessions, and that's the slave. In
particular, I don't want to have code in gdm-binary that just routes
messages around, there is already too much of that in gdm.

>> I think we want to keep org.gnome.DisplayManager for now. If any, it
>> helps with gdbus-codegen to have one prefix for all interfaces.
> sure.
>
>> Ok. It shouldn't be difficult to add it on top of the existing
>> interface (if a libgcr dependency is ok for gdm)
> Should be fine.  Anyway this part is somewhat orthogonal to the rest
> of the work.

Speaking of orthogonal parts, I also started a big GDBus rewrite of
gdm. I'm doing this because I'm not confortable with libdbus, and
because it causes a good deal of code to be replaced by gdbus-codegen.
I'm not done yet, but I'm trying to make sure that everything builds
and works after each commit. You can find progress at
https://github.com/gcampax/gdm/tree/gdbus-port (or, if you prefer, I
can move it to git.gnome.org).

Giovanni