1) modular GUI design 2) internationalisation 3) CLI
1) modular GUI design : =======================
I think that an important requirement is misssing.
We are designing a very modular OSCAR however, the GUI is monolithic. This can't fit together : the modular design will be "destructed" by the monolithic GUI design.
We are confronted with this problem with, for instance, the thin-OSCAR project. How can we add options to the existing GUI ? To any monolithic GUI ? How can we integrate with the current stuff ? Should any package author have access to the OSCAR GUI and be able to "patch" it in order to fit his needs ?
This is a good point... everyone agrees that modular is good, and would be much more extensible.
As a consequence, I'm convinced that we need a kind of general GUI framework for OSCAR. Rebuilding the actual monolithic GUI will not provide this functionality. The modular GUI design is a consequence of the modular OSCAR design and we must ensure that we do not break this modularity by writing a GUI that has to be modified each time someone add a functionality to OSCAR (which is the actual case and will be the case of a "simple" rewrite of the GUI).
2) Internationalization : =========================
If we want OSCAR to be successfull, internationalization should be a requirement of the GUI engine. UTF8 & co ...
3) CLI & Text based install: ============================
This is, I think, a very important point. The point & click approach is not scalable.
I completely disagree here. The point & click approach, if anything, is MORE scalable. Granted, there are point & click interfaces that don't scale well. If they don't, then something was done wrong. On a large scale, scaled addressability and visualization become very important, both of which a GUI has potential for. The blinking cursor gives me no indication of what the cluster looks like, what options are available to me, current status, etc, etc, etc! A GUI encompasses all the functionality of a CLUI with the exception of scripting, which can be done with the command lines behind the GUI if the GUI is built that way.
I would never boast any scalability in our current GUI, but the GUI concept definitely allows for it if it's done properly. Limiting our GUI to menus alone will likely lock out any possibility of taking it to potential, incidentally.
We made some progress with the automatic MAC collection but that does not cover everything especially if we want to provide a true "cluster framework".
The generally acceptepted best practice for any server is to install
only the requested services & components. All the server I manage don't have and
don't need X. If I had the choice, the OSCAR head-node would not those
thingy...
Actually, if you want an OSCAR cluster, it DOES need X. It should be seen that way instead of "OSCAR is the only reason I need X, so let's change OSCAR". X isn't necessarily an evil bad thing. For routine maintenance on the other hand, I agree, it's nice to have CLI utilities. Also, when the GUI is re-written, I have a feeling it will have CLI behind it, which will allow for anyone to script the install as much as possible. However, if a helpful feature that can be put into the GUI is extraordinarily difficult or impossible to make a CLI equivalent for, I don't think we should bother wasting time on it. If someone has a specific need for it so they can avoid running X, running X over a modem, or whatever... I vote to leave them to make their own solution. OSCAR has plenty of other development needs that need more attention.
I don't think it is a good idea to separate the :
- CLI
- text based install
- graphic install
- web install
I definitely understand the benefits of combined interface API, but I think they're far outweiged by the following problem: Each one of those interfaces has it's own set of limitations. If you don't separate them, you just add the limitations up to a large sum for all interfaces to be hindered by. By and large, OSCAR will be installed with the same interface, and we better make it good.
My foot is now stuck in this horse, and it's not breathing. ;-)
Jeremy
-------------------------------------------------------
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
