Short version: ==============
I think that in order to progress OSCAR, we need to re-write the installer. I am *not* in favor of "fixing" what we have -- I think the effort would be the same to a) fix what we have, or b) re-write it with a solid design.
I agree that something needs to be done to improve the installer. I agree that major changes could benefit us, thus re-writing is a more realistic goal.
Let's also remember that as the OSCAR working group, it's our *main job* to concentrate on the *functionality* of OSCAR, not necessarily how pretty it looks. Of course it should be professional and functional, but "pretty" should definitely be a secondary concern.
Since functionality is already there, interface is what matters now. Interface is what makes OSCAR marketable, and is what makes OSCAR appeal to the masses. Because of the great number of little scripts we have to run during an install, we're not far from a CLUI.
===============
What we have needs to be redone -------------------------------
For anyone who has looked at the installer code, you know it's a pile of junk. It's functional, yes, and it does a reasonable job, but it's hack upon hack upon hack upon hack. It was written in the "pile of mud" design philosophy -- little pieces were added here and there over time until we have what we have now: a large, complex, heavily inter-related chunk of code.
I would argue that the code is not "junk". It's not perfect, consistently-styled code, but it's decent. Above all, it works. Looking at the map of metamenu and its presentation layers, the GUI layer (and likely the text-based layer) would consist of a proper base with sections added by various people down the line as features are needed. In the evolution of a large software product written by various people with different training at different facilities with limited communication, software "mud" is somewhat inevitable.
This makes the code difficult to maintain, difficult to extend, and difficult to progress -- mainly because there is no overall design. Hence, there is little modularity, and different pieces of the installer unexpectedly depend upon each other (leading to cascading failures when you try to modify something). Some parts are better / more modular / more robust than others, sure, but that's not the point.
Again, I would argue that the GUI is not terribly difficult to maintain or extend. Before a short while ago, I'd never really looked at GUI coding, but I added buttons and functionality to various windows in the wizard. Though I'm not the best GUI coder around, I fit my code in as best as I could. There are odd dependency issues which lead to odd failures, and a rewrite should address these.
For this very reason, I do not believe that moving towards a simpler interface (GUI) is "moving backwards". The drawbacks of our current system are *so severe* that if we have a simpler interface system, the benefits (in terms of functionality -- our main job) greatly outweigh any drawbacks of having a simpler interface (GUI).
A *simpler* GUI is not moving backwards. A GUI with limited functionality *is*.
Before attempting to answer that question, I think some of us have lost sight of our ultimate objective: to make Righteous, Dang-Blasted, Awesome Cluster Code (RDBACC). Of course it has to look professional and be functional to novice users. But it also has to work for advanced users (e.g., why we need a real CLUI interface).
I think that because we easily set up a working cluster with little chance for major screw-ups, we *have* RDBACC (or something approaching it). First... since most users will use a GUI to do the installation and since the GUI is OSCAR's "face", we should focus on making it the best we can make it. A CLUI, while somewhat useful for some tasks, is a secondary goal which can be attained without the use of metamenu.
Our funding streams are all tied to getting *funtionality* -- adding featues and making RDBACC. And I was somewhat serious yesterday when I said on the call that none of us have the expertise to make "pretty" looking applications. It is really not worth our time to design sophisticated GUI applications with glitz and animations -- nor is it our charter / mandate. That is *NOT* the point of what the OSCAR group is for.
I think that most anyone can make a "pretty" looking application. It is very much worth our time to make a sophisticated GUI app for many reasons. I would probably recommend against superfluous glitz and animation though.
For example, what is more important: having a button line up exactly, or having the ability to use a password for MySQL ODA databases? One directly impacts security, the other is glitz. I think the choice is clear.
I think both are important. In general, the button lining up is more important and more relevant to more users. BTW, we have a working MySQL password prompt (in Tk).
And remember that having a CLUI interface (or XML or ...) would [potentially] allow someone to write glitz on top of the installer. Someone more qualified than us, and someone who has the time and resources to do it.
I think that we should have a great backend, calling various scripts, etc. It won't be a CLUI, as you seem to propose, but it could be scripted. Our GUI should make the backend scripts, etc. useful by asking for and performing actions with the appropriate information.
I'm *not* saying that we don't need to worry about the presentation of OSCAR. Of course we do. Of course we have to have a professional-looking installer (and I challenge anyone to say that the one we have now is professional looking -- look at the logo again and try to defend that position :-). Of course we need to have it "easy enough" to use for novice users -- that's the goal of OSCAR, after all.
I would say that the current installer is professional-looking. I don't see why it isn't.
What I'm saying is that we should be channelling the majority of our efforts into cluster-based functionality (RDBACC), such as the ambitious designs and goals that we outlined at the IU meeting. The interface will follow, and it will be reasonable, professional, etc. But worry about functionality first, or the whole interface issue becomes moot. Simply put: why argue about interface before we even have the functionality? Doing so will lead into a tar pit, and we'll never get the functionality for fear of not being able to support amorphous, arbitrarily complex vaporware GUI's at some point in the indeterminate future.
Since we have functionality, we don't want to lose the quality of the interface we already have.
When we started talking about this last October/November, I trolled around on the web and talked with Sean Dague (who knows much more about this stuff than I), and we pretty much came to the conclusion that there wasn't any other tool out there (currently) that did what we needed it to do. Hence, MetaMenu was born.
I would agree that there probably isn't anything out there for free to do this in Linux.
But if it's not "enough" -- fine. Let's do something else. I have zero problems with that. But let's do the Right Thing, not a GUI-based solution solely for the sake of glitz.
For the audience of OSCAR, a GUI-based solution is the Right Thing. The backend can be in whatever format you like, but if the backend limits the GUI, it won't work for our purposes.
- able to run in a variety of environments (text-based, CLUI, GUI, etc.)
The GUI is most important, ideally based upon command-line utilities. I would suggest that SIS's panels, which call command line tools, have a good thing going.
- completely separate functionality from presentation
Part of functionality is displaying something, except when speaking of the CLUI. Text or GUI installation requires prompting for, displaying, and changing information. A CLUI installation requires knowing all the options, then entering the command. In this way, the text or GUI installation should be using a CLUI backend. If someone really wants to script the install, go ahead and figure it out. If you want to run the installation as normal, call the installer and it will ask you for info, display results, check answers, resolve errors, etc. There is no "selecting/deselecting" in a CLUI... in a GUI, things can be done upon each select/deselect. In this way, the presentation is not entirely independent of functionality.
- 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
I would argue that metamenu is not the answer to our prayers. I would propose a strong command-line interface (i.e. a bunch of scripts/.pm's) driven by a GUI installer. If a text-based install is wanted, a package can be made for it. If various helper scripts are wanted that make it as simple to install on the command line as it is with the GUI, a package can be made for it.
I think we should improve upon the installer. I think a rewrite is in our near future. I think we should look somewhere other than metamenu, unless it turns into a simple FSA that calls scripts based upon a state transition table. We need more than menus, we need a full interface, and that means more than what metamenu can offer us. As Jeremy touched on, we could move to a different language (Java, C++, python, whatever), or a different GUI toolset (GTK, QT, Swing, (perl-)Tk).
That's my opinion... Jason
-------------------------------------------------------
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
