ConsoleKit 0.2.4

[Michael Biebl]

2008/1/24, William Jon McCann <mccann at jhu.edu>:
> On Jan 24, 2008 9:06 AM, Matthias Clasen <matthias.clasen at gmail.com> wrote:
> > On Jan 24, 2008 5:15 AM, Danny Kukawka <danny.kukawka at web.de> wrote:
> >
> > >
> > > Btw. There is also absolute no reason to move any kind of powermanagement
> > > stuff to CK. I would bet: Nobody of the powermanagement developer would like
> > > to maintain/handle another (additional) tool for pm-tasks. HAL should do the
> > > job, this is what all the distributions decided and do now for good reasons.
> >
> > Again, somebody should show the imaginary layers that keep being mentioned here.
> > These are just dbus services on the same bus.
>
> Also, I'm failing to see how shutting down system services has
> anything to do with a DeviceKit.

See it the other way, what has ConsoleKit, which was conceived to do
user/session tracking, to do with System tasks like reboot/shutdown.
Simply nothing.

About the layer boundaries:
+--------------+
|    HAL       |
+-----------+  |
| PolicyKit |  |
+-----------+--+
| ConsoleKit   |
+--------------+

What you have is ConsoleKit at the bottom, providing information about
logged in users and sessions.
PolicyKit is about centralizing the decision making process when to
grant access to a privileged operation for and unprivileged
applications. For the allow_(in)active constraints, it queries the
information from CK, so it has to sit on top of ConsoleKit.
HAL lastly sits on top of CK and PK. PK is queried when authorized
operations are to be executed and CK is queried for stuff like the ACL
(/dev) management.

So, a software which provides the Shutdown/Reboot methods has to sit
on top of PolicyKit. As HAL is already there, it's the natural place
to put it.

If you start violating these layer boundaries in your software stack,
you get a huge pile intertwined components with cross dependencies.