Re: [Setup-tool-hackers] boot-admin error??

[Arturo Espinosa Aldama <arturo ximian com>]

On 10 Feb 2002, Carlos Garnacho wrote:

> El sáb, 09-02-2002 a las 02:31, Joakim Ziegler escribió:
>
> > Looking good, I have some suggestions, though:
> >
> > You shouldn't really need to show the priorities as numbers. They're
> > really just a way of doing ordering when you don't have any other way to
> > do it (a trick that works because ls lists them the right way, and it's
> > easy for the init script to do it right). The best way to do it would be
> > to just show the list sorted in the order things will start up, and have
> > "up", "down", "top" and "bottom" buttons to move things around (or allow
> > drag and drop, but then you'd have to use ETable).
> >
> > Also, kill and start are separate, and should probably be separated in
> > some way.
> >
> > The tabs are problematic. I agree with Arturo saying that simple mode
> > should only show the default runlevel, but perhaps the runlevels should
> > be shown as a tree view in the same pane, instead of as several notebook
> > tabs.
>
> I agree with you. Using 7 ETables is neither efficient nor fast. I'll
> try to do it with a ETree. Do you know where can I find documentation?

I think Ryan's suggestion of using one ETable with a column for each
runlevel is the best idea. Joakim is right about the ordering: the user
doesn't need to control the exact number, and this helps us because then
the "one etable for all"  implementation becomes quite fit.

Still, I repeat that this switch shouldn't be performed if it takes too
long: we should better wait for after the next release (I have asked Chema
to make a new release of the XSTs soon).

> >
> > How does the "add service" and "delete service" actions work? Delete
> > should of course only remove the symlink, add should probably present a
> > list of available init scripts (from /etc/init.d/) that you can symlink
> > in. You might also want to have the option to disable things to, that
> > is, not delete the symlink, but rather rename it so the name is prefixed
> > with DISABLED or something. As far as I know, init does not run the
> > script if it doesn't have the right name format (^[KS]\d{2}.*), so you
> > can disable things this way and still know that they're there. In fact,
> > this could be a replacement for Delete, because deleting things is not
> > really useful (or maybe delete should just be in advanced mode). Then
> > you can just have a column with a checkmark to say if this service is
> > enabled or not.
>
> I cannot see the functional difference between deleting and disabling,
> but if you (you all) like the idea i'll do it.

I think disabling is complicated, and it doesn't save the user much work
because there's almost no information lost (compare that with the
difference between deletting and disabling a user). I think
functionality vs complexity in this case wouldn't turn on our side here.

> >
> > Additionally, you should have the option of starting, stopping,
> > restarting, etc. the scripts. To achieve maximum flexibility, you can
> > call each script with -? on startup, to get the list of options they
> > support (all scripts give an easily parsed list of options inside of {}
> > which you can split on |), and then have a mapping of known option names
> > to actual button labels. Here's a partial list for that:
> >
> > start       Start
> > stop        Stop
> > restart     Restart
> > reload      Reload Configuration
> > condrestart Restart If Running
> > status      Get Status (pop this up in a requester, perhaps?)
> >
> A good idea, but:
>
> Do you talk about using XML to do this? I think that the backend should
> be the only part in the program that treats with the configuration.

Yeah, and I see no problem here. I agree with Joakim here, but only for
advanced mode. The beginner user is probably more comfortable with just
start and stop buttons, which keep the boot-time and current status of
each service consistent. Advanced users can cope with a more complicated
mapping of the system, where the current running status of the services
may not be the same with which services will come up or not when switching
runlevels.

I would allow status for both simple and advanced mode.

> If we do not use the backend to do this, the frontend will be doing
> things that the backend should do.

No, we just call a backend directive that activates/updates
links/whatevers a service when one of the restart buttons is pressed
(check the network frontend's callback on connection activate_clicked for
a refference of how this is done).

The order in which the services are started or stopped will thepend of its
order on the list. If this is not good enough (the user not having enough
control of the timing of multiple services starting or stopping?), then
we'll have to make the Start and Stop buttons immediately call their own
directives when pressed.

> > What does Edit Service do?
> >
> nowadays nothing.

And I think that if we are going to drop the manual order setting, we
should drop it completly.

> > Another very useful thing to have would be a list of known services and
> > their descriptions, short and long descriptions, short ones to use in
> > tooltips in the list, and long ones for a "What's this" type help
> > button. I'll volunteer to write this list for you if you will implement
> > it. In fact, it might also include a better name for the service than
> > the script name, so the list becomes really friendly and nice.
>
> That is a very good idea. I'll implement it. How do you send the list to
> me?

This is an excellent idea. We'll revert to the name of the init.d file
name if no nice name is provided by the backend. This is just adding a
couple of tags to the info that comes with every service.

I would also suggest putting this information in a sepparate .pl file to
make simple contributions easier. I suggest using the following structure:

{"common" =>
	{"service1" => ["The long name of the service1", "Description"],
	"service2" => ["The long name of the service2", "Description"],
 .
.
.,

"debian-.*" =>
	{"service2" => ["Name for debian name of service2", "Desc"],
	.
	..
 .
.,

 .
.
}

The idea here is that the "common" strucutre will contain most of the
descriptions, but they may be overriden by other entries in other
structures, maybe because of a clash in the init.d script naming between
platforms (this could be particularly true with commercial unices, which
we may support later).

So, common will contain most of the info, and the other structures just
the exceptions. The keys of the top-level hash are regexps that are
matched against the platform name - except for "common", of course.


And yet again, I would leave this for a future release. In fact, I would
leave most of these suggestions for the next release, so we deliver
the runlevel-admin soon, and then let the interface mature later.

Greetings,
Arturo



_______________________________________________
setup-tool-hackers maillist  -  setup-tool-hackers@ximian.com
http://lists.ximian.com/mailman/listinfo/setup-tool-hackers