Re: [woody,debinst]

[Joey Hess <joeyh@debian.org>]

Esben Haabendal Soerensen wrote:
> 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.

I wasn't looking at the UI as one big monolithic user interface that has
to know about everything. It's just the code needed to actually draw the
screen and take user input, plus some hooks to allow modules to control
it. If you're familiar with debconf, there are parallels. Or look at it
as more of a type of widget set.

> 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.

Hm, but worker modules and UI modules would really be pretty tightly
bound. If you have a network configuration module, and a worker module
that then actually initializes the network, the worker module may just
load a kernel module and ifconfig it up. Or it may use dhcp. Depending
on what it does, the UI module needs to get different information from
the user. So you actually have a set of several tightly-bound pairs of
UI and worker modules for network configuration.

> 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.

Note though that debconf also allows for this, without having to split
off two types of modules.

-- 
see shy jo