To that end, I'd like to make a first stab at requirements (these were actually what I had in mind when I designed MM):
- able to run in a variety of environments (text-based, CLUI, GUI, etc.) - completely separate functionality from presentation - support a fully modular design such that adding a new installer step "in between" two other steps is not difficult - able to provide stable yet flexible ordering of modules (installer steps) such as pre- and post-requisites, etc. - allow arbitrary code to be insertted at any point in the process
My requirements for the installer are:
- able to run as a very easy to use GUI with lots of features
- designed so that a main driver program does the very simple sequencing
- designed so that the main driver program never pops up a window
- designed so that all of the "actions" being performed can be done on a command line over a modem
I'm not tied to MetaMenu -- if MM is not "enough", then let's do something else. Other proposals would be appreciated.
Here is my proposal:
1. The installer consists of a simple program that calls a half dozen or so "steps". It really only needs that many, think of the steps now, except that they would have sequence enforced. The installer probably never even needs to do any of it's own windows or GUI.
2. The steps are separate programs that pop up their own windows. We have some of them in a rough form now, the selector, the configurator, the mac address and network setup step. Each step program returns a status to the main program that says next/back/quit or whatever. The step programs pop up sub-windows as needed. The step programs call "action" programs to actually do anything.
3. All "actions" are done with command line programs that do NOT prompt for input values, they just accept command line flags. This should be the bulk of the OSCAR installer code, and works for both GUI and CLUI flavors. One action program would be to make a new oscar image, etc etc.A lot of the action programs that just store or update cluster configuration data would just be oda shortcut commands.
4. Whoever really can't live without a CLUI installer, is welcome to mimic the step programs, or replace the entire installer/steps system. I would think that they would want to write the whole CLUI installer thing using metamenu or a similar sequencer. Perhaps the main sequencer program could call the GUI versions if DISPLAY is set, and the CLUI versions if not.
This will let us advance the OSCAR installer quickly, by improving the GUI installer in incremental steps, while allowing a CLIU installer to be done in parallel, with neither limiting or impacting the other's development. This will prevent the coming limbo where we are developing this massive GUI and CLUI installer system. This allows for easy incremental moving towards a better GUI installer that has the underlying action programs that a CLIU installer should share.
The problem with having a sequencer drive both designs is that they are not similar in their implementation, For instance, the mac address collection and network setup GUI window does a lot of stuff, that is not written in the same way that a CLUI equivalent segment is done. If they are, the GUI version has to be severely limited. I don't see any reason to have the GUI installer be limited by the sequencing logic of the CLUI installer. And I don't see any reason to waste time re-doing the GUI stuff to try to impose a sequencing model on it, except for the overall steps.
-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com
_______________________________________________
Oscar-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/oscar-devel
