Does ConsoleKit support such kind of functionality? Regards,
Jedy On Thu, 2009-09-03 at 02:32 -0500, Brian Cameron wrote: > On 09/03/09 02:02, Joerg Barfurth wrote: > > Jedy Wang schrieb: > > > >> For example, ConsoleKit DBus service daemon currently provides 2 DBus > >> methods, Stop and Restart, to shutdown and reboot the system. We can add > >> 2 new DBus methods, FastRestart and ColdRestart, to support fast reboot > >> and reboot to prom. > >> > > > > I don't think a multitude of platform-specific methods is the best > > approach to add platform-dependent specializations to an essentially > > platform-independent interface. If you later want to add support for > > boot-to-specified-BE, you'd need more methods. > > +1. Ideally any "options" should be configurable so that each distro > can specify what options make sense for their system. Adding new > interfaces like "FastRestart" or "ColdRestart" does not sound like a > very generalized solution to me. > > Perhaps a better solution would be if ConsoleKit provided an ASCII > configuration file where you could specify various options that should > be provided as modifiers to Shutdown or Restart. Then ConsoleKit > could provide an interface so that the GUI could retrieve those > possible options, perhaps with hints figuring out how to display > them (as checkboxes or comboboxes or whatever). Then any options > selected by the user could be passed back to ConsoleKit in a new > argument to the existing Shutdown/Reboot interfaces, and the shutdown > or reboot scripts (which are already system specific) could figure out > what to do with them. > > > A better approach could be a pair of getBootOptions/setBootOptions > > methods or an added bootOptions parameter for the restart and > > shutdown(?) methods, which allow passing a set of named parameters (as a > > map/dictionary). Through getBootOptions (or a separate method) it should > > be possible to query supported options. > > I think we are sort of suggesting the same sort of thing here. :) > > > I'd assume such a generic approach is more palatable for upstream. > > I'd think so. > > Brian > >
