* The current GUI is a kludge, and difficult to add to. It is also not all that professional looking.
* Modularity is a Good Thing.
* A CLUI would be nice (I differ on the emphasis here tho)
* Re-writing anything in any way is going to be expensive
I differ based on the following:
* The importance of a CLUI is grossly exaggerated.
First off, I'm not suggesting that we don't have a CLUI. However, a CLUI didn't make OSCAR what it is, and will never "make" OSCAR. A GUI always has, and always will. That should make it a clear priority. We had certain attendees at the 9/11 meeting that got the group all fired up about the importance of a CLUI. Those attendees haven't contributed byte 1 to OSCAR thus far incidentally... that's actually ok though.
If we need specific functionality like adding a package through a command line, it wouldn't be terribly hard to add such specific parts. Being able to install the entire cluster via command line, however, I think is cool- but a waste of our time for what it's worth.
Now- if you insist on being able to use the OSCAR interface over a modem, technically X is possible. It's getting frustrating to hear that point anymore. I mean really, if you're using a modem, it's your own darn problem- stop whining.
Next reason to have a CLUI- so others can take OSCAR and make what they want of it. My feeling is that most entities that decide to take OSCAR and roll their own will just include OSCAR's GUI right along with it. In fact, this has been the case already (Gelato). Granted, we don't have a nice pluggable interface yet, but I honestly don't think it would have mattered from my meetings with them.
I'll end how I began, reminding that I'm not saying not to have a CLUI. I'm saying NEVER do anything in order to have a CLUI which limits the GUI. The MM path conflicts with that.
* "Pretty" is much more important than it's given credit for.
If you don't think pretty is important, maybe you didn't hear what Tom mentioned on the call yesterday. To us nerds, it doesn't matter. If you're talking sales (free sales or not), it is critical. I'm "selling" OSCAR all the time to new users... Neil is as well. It is not a gray area... it is crystal clear, black and white, whatever... just trust me, users will make decisions based on that. The example of "ODA password vs. button that doesn't line up"... I'm actually on the fence there. Not to be cliche, but Windows didn't achieve it's success and current foothold by doing The Right Thing. It was the interface, and relative to alternatives, it was pretty. OSCAR will be more successful releasing something pretty with messy code behind the scenes than it will releasing perfectly architected code with a mediocre frontend. I believe that firmly.
* I don't think MM's benefits necessarily outweigh it's drawbacks.
I agree that simple is good, and MM itself may be just that. However, for OSCAR to use MM, and tieing 3 different interfaces to the same structure and still getting everything we want is anything but simple, and really not even possible. And why the readline interface, anyway? CLUI buy's us scripts, GUI buys us pretty + simple; what does readline buy us?
As Jeff pointed out on the call, MetaMenu is just that- a MENU utility. Limiting the GUI to that when we don't absolutely have to is asinine. For one, we already have GUI items that don't fit that scheme. What's more, it's naive to assume that a menu interface like that is all we'll ever need. I think that's a very popular mistake we're making... when we assume that the MAC collection kind of interactive functionality is all we would lose. No... we lose potential to do any other cool interactive things in the future too. I don't want to have another layer of dependency before we can even think about adding an interactive feature.
So at a higher level, I think much of the complication that I have a problem with is our attempt to bind the UI's to the same infrastructure (MM or anything else). It is limiting the GUI, and I think of all "Bad Things", putting up iron clad walls to our future is #1 badness.
A long time ago, Terry suggested we _start_ this project with a requirements list, rather than starting with a design. I'm starting to listen to that now that we have a proposed design that doesn't seem to fit the requirements. I didn't know MM was going to be so limiting though. I definitely would have chosen not to waste anyone's time if I knew better. I think MM was probably the simple part of the project though... putting a GUI on top of it would by far be the most difficult.
So Terry had an idea that maybe he could flesh out here... basically, it was like this:
Each panel that comes up right now in our wizard is a separate module, with a very simple overhead layer which gets changed to add/remove, change order of any sub modules. These individual modules are each independent of each other, but share a common datastore to read/write to (could be ODA if we want). Anyway... the design is that each module is responsible by itself to identify if it has everything it needs to run or not, by looking in the datastore or whatever. These modules could even be launched in command line mode to fit the CLUI scheme... but still each individually responsible for being intelligent. To change/add/remove, we still only modify the overhead layer of it all. This design lends us with CLUI options, modular design, maximum flexibility in GUI design and easy modification. One window to the next wouldn't even have to be the same language, although I wouldn't recommend that for a consistent look of course. The point is, we're allowed to if we want to in the future.
Miscellaneous questions:
Why did I hear chuckles when I said "java" on the call? Seriously- what's crazy about it? I've been told that it's one of the cleanest languages around. Let's not forget that the ultimately portable Perl broke down on us just crossing major releases of Redhat.
Anyone ever tinker with "Dialogue"? I guess it's the MM kind of engine that runs things like "make menu/xconfig" with kernels.... I know nothing about it further than that.
Jeremy
At 08:31 AM 3/5/2003 -0500, Jeff Squyres wrote:
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
-------------------------------------------------------
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
