Re: [woody,debinst]
>>>>> "Joey" == Joey Hess <joeyh@debian.org> writes:
Joey> The question of how the UI should work is the weak point of my
Joey> current proposal. I've been wrestling with really two orthagonal
Joey> issues:
Joey> 1. How should the UI work? I rather like most of our current UI,
Joey> but is it really the best way to handle things or have I just
Joey> become accustomed to it? My proposal is to have a modular
Joey> installation system, which means that modules need to be able to
Joey> hook into the UI. Note that this is not about UI toolkits, but
Joey> about UI design.
Joey> 2. How should information from the UI be stored, for use later
Joey> on (and, presumably, for use in a kick-start like thing to
Joey> anable mass installs)? Here debconf seems like a fair fit,
Joey> although it would have to be redone in C.
I think it is a good idea to turn this design up-side down.
The basic design component should not be the UI. I suggest that the
basic design for the woody installer is based in the actual
installation proces, making the modularity concept even more
powerfull.
With a framework based on the installation proces, there will be two
types of modules to be plugged in:
* UI modules. These modules are used to query for the necessary
parameters to be passed to the other type of modules, the worker
modules. Examples are a network configuration module, xfree
configuration module, and a package selector module.
* Worker modules. These modules are in charge of carying out the
actual installation work. Examples are a partitioning module and a
base system installer.
The name "UI module" is actually badly chosen, as this is where the
hooks needed for mass installation is provided. By providing
non-interactive modules for all necessary UI modules we have a fully
automatic installation in play. With this abstraction idea it will be
simple to write automatic installation support based on LDAP, MySQL,
flat-file on NFS, flat-file on CD, or whatever is apropriate.
The worker module abstraction might be prove to be a good way to
approach the architecture dependent tasks in the beginning of the
installation proces.
Those who have looked at the Anaconda design will see where the
inspiration comes from ;-)
My $0.02
/bart
--
caffeine low .... brain halted
Reply to: