Jedy: > Does ConsoleKit support such kind of functionality?
Not yet. Brian > 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 >> >> > >
