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.
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.
I'm not tied to MetaMenu -- if MM is not "enough", then let's do
something else. Other proposals would be appreciated.
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.
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.
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).
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?
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).
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.
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 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.
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.
MetaMenu and others
-------------------
MetaMenu was conceived to be a simple solution to this problem. I do
*not* believe that MM is the be-all, end-all solution. It was
envisioned to be a fairly simple answer that provided the
functionality that OSCAR needed, but did not try to be glitzy.
As I tried to make clear on the call yesterday (and in all previous
discussions of MM):
- it definitely entails re-writing much/most/all of the current
installer in terms of MM states
- it will not be a glitzy solution
- its benefits outweigh its drawbacks
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.
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.
But also remember: if you accept the premise that we have to re-write
the installer, then *anything* that we do will be expensive in time
and resources. So MetaMenu is potentially no worse than other
proposed solutions.
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)
Comments?
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} http://www.lam-mpi.org/
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Oscar-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/oscar-devel
