Re: [woody,debinst]

[Esben Haabendal Soerensen <bart@sunsite.auc.dk>]

>>>>> "Joey" == Joey Hess <joeyh@debian.org> writes:

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

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

Ok, I see I have to look into debconf before arguing much more about
this.

Maybe debconf is an OK tool for this job, but won't it make it
harder to implement an alternative frontend, or to rip out all ui
frontend to save space for a mass installation ?

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

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

Sure.  UI and worker modules as I describe above would be tightly
bound, but not necessarely in pairs.  A single UI module might provide
answers parameters to many worker modules (fx. a LDAP or DB module),
or there might be more than one UI module providing parameters to one
worker (some answers might come from a flat-file or LDAP module, and
the rest from a GUI module).

So yes, there will be a connection between UI modules and worker
modules, but it is still a good idea to at leas have this design idea
in the back of the head when proceeding with the woody 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.

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

Well, I don't see the split as a loss ;-)  But I *can* appreciate the
idea of using debconf for the installer as long as no important
disadvantages are introduced with it.

/bart
-- 
caffeine low .... brain halted