In response to Jeff's comments...
> Longer version:
> ===============
>
> 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.
>
> 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.
This is almost always the case for large projects that evolve over time.
Thus rewrites are usually a nasty reality that people accept to create
better applications for the future.
> The point is that there's no overall design. NCSA has (righfully)
> complained multiple times about the lack of documentation about
> Package.pm (and friends). Everything is done in an ad-hoc manner,
> sometimes (usually?) without regard to the overall system.
Then perhaps the main issue here is to go back and build from the ground up
rather than top-down. Since we are using Linux systems, let's adopt the
Unix philosophy of building very small command-line tools and then build
larger tools on top of them, etc, etc, until you have a GUI at the top
layer. If you take this approach, you have your CLUI almost written for
you.
Another benefit to this approach is that half of the work has already
been done by oda. Take for example the Selector. I need to be able to
select/deselect a package, display information about a package, list all of
the packages (selected/unselected), etc. All of this functionality has
already been written in oda. So, the low-level command-line tools are
there. Rewriting the installer then requires that we extract out the
functionality of the current code and put it into small command-line
executables. This will automatically modularize the code and reuse code
that is already there.
> 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).
I think that a simpler GUI will be construed as a step backward by any
casual user of OSCAR.
> So "fixing" what we have (IMHO) is not workable. What we have is so
> broken that "fixing" it would essentially be re-writing it anyway. So
> my proposal is to shed the pretense of "fixing" the current stuff and
> re-write [essentially] from scratch.
>
> If we can agree on that (or at least take that as a premise for the
> rest of my discussion below, even if you don't agree :-), the questions
> become: how do we re-write it?
The FIRST step should be to sit down and write a requirements document.
This is a fairly radical concept in software development (sarcasm intended)
where you decide WHAT you need your application to do, not HOW you want it
too look. When you say CLUI, what exactly do you mean? Is the "ls" command
a CLUI? Is "linuxconf" a CLUI? If you can write down exactly what types of
actions you perform with your cluster, then you can write small tools to do
exactly those actions, nothing more. If you want to automate a sequence of
steps, then you use these tools as building blocks for another tool.
Eventually, you can look at the requirements for a GUI. The requirements
for a GUI are very different from the requirements for a CLUI. By using a
system such as metamenu, you are trying to force the CLUI and the GUI to
meet the same set of requirements.
> Professional, not [necessarily] pretty
> --------------------------------------
>
> 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).
What advanced users need is a set of command-line tools to perform exact
functions.
> 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 have been working on GUI development since 1988 back when the only tools
available were X11/Motif and Windows/VGA low-level programming. I don't
claim to be perfect when it comes to designing user interfaces, but I think
that I DO have the expertise to make "pretty" looking applications. Thus,
please do not make crass generalizations like that. I would bet that there
are many hidden talents in the members of this group.
The reason our current installer is not "pretty" is because we are using
Perl/TK as the GUI development environment. If we were to use another GUI
platform (Qt, GTK, Java, whatever), we could most definitely make "pretty"
looking applications without having to spend lots of time worrying about the
user acceptance of our program. I think that the vast majority of the
public DOES respond to "pretty" applications more than super-powerful
software. As someone mentioned on the conference call yesterday, LaTeX is
much more powerful (IMO) than MS Word, but you don't see 90% of business
users writing documents in LaTeX.
> 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.
And yet, the first thing a user is going to notice is that the button is not
lined up exactly. This will most likely give the impression of an
unprofessional product, regardless of how wonderful the underlying software
actually is.
> 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'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.
So here you say we need to have an application that is "easy enough" for
novice users, but above you said that making a sophisticated GUI application
is *NOT* the point of what the OSCAR group is for. First, I challenge you
to convice novice users that a CLUI is "easy enough" to use. Second, I
challenge you to find somebody outside of the OSCAR group to write a
"pretty" GUI for us. I think that making a "pretty" application is very
much a part of what OSCAR is about. Without a GUI that allows people to
install and maintain their cluster, people are apt to look elsewhere for a
solution that is pretty and easy to use, even if it has less functionality.
I really don't see how anyone can claim that a CLUI is "easy enough" for
novice users. Case in point: there are plenty of reasons why Unix is a
better OS than MS-Windows, yet it is only recently that a nice GUI has
allowed Linux to even start being considered as an alterative to Windows.
> 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.
Yes!!! I agree completely! So let's build the basic functions first.
> How to proceed
> --------------
>
> So back to the question posed above: how to re-write the installer?
>
> First off: we really need to have a real design. I'm fine with rapid
> prototyping (after all, we *are* only talking about several thousand
> lines of code, so OSCAR is "large" but nowhere near "huge"). But
> there should be *some* overall plan and adherance to developer style
> and guidelines.
>
> 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
>
> (donning flame retardant suit)
I do not want to beat down metamenu. There are some excellent ideas
addressed by metamenu, but I think that we need to take a different approach
to the problem.
Here's what I would like to see.
(1) Figure out the basic functions that a user would need to do to install
and maintain a cluster. Write the functions as small command-line
tools. To do this, we need to break out the existing code into smaller
units/modules.
(2) Decide on a general "flow" for an installer. This would be a sequence
of events that need to occur to install/maintain a cluster.
(3) Build "larger" tools using the command-line tools in (1) to perform a
sequence of multiple actions. These tools would handle their own pre-
and post-conditions. That is, a tool would not run unless everything it
needs had already been done, and would not quit until everything it
needs to do is finished.
(4) Build GUI windows on top of the tools in (1) and (3). Each GUI window
would be a stand-alone application. Similar to (3), each GUI
application would run only if all of it's "prerequesites" have been met,
and will exit only when everything it needs to do has been done. The
exit code would determine what should happen next (eg. Cancel, Next,
Previous, Failure, etc.)
(5) Build a meta-application that acts as a deterministic finite state
automaton (DFA). This application describes the sequence of "states".
These "states" are individual applications from (3) and (4).
This means that every step of the installer is a stand-alone application,
be it command-line or GUI. Each stand-alone application handles it's own
pre- and post-conditions. The DFA simply says the order to execute the
applications. Note here that you could easily create separate DFAs for both
a GUI and a CLUI.
Terry Fleury
[EMAIL PROTECTED]
-------------------------------------------------------
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
