[Evms-devel] Re: [Evms-announce] Initial GUI Design Document release

[Andrew C. <cl...@gn...>]

On Wed, Jun 13, 2001 at 12:25:24PM -0500, steven pratt wrote:
> I think we are making a molehill out of mountain here.  I completely
> disagree that merging all of the layers in the Engine is a 'minor issue'
> or that it would lead to a 'simpler design in the end'.  When you only
> think about the implications of "discover' this may be true (which is
> why in the kernel we have a common function table and node structure
> across the layers), but when you take into account the complex
> operations of configuring and modifying partitions, volume groups, and
> features it become an overload.

Well, I disagree.

> Sure we could just max define all the
> function table and data structures and have each layer ignore 30-50% of
> the APIs and fields, but does that actually simplify anything?

That's not what I mean... I'm thinking of "inheritance".  For example,
a storage object could be a logical disk... as far as features are
concerned, they just need an address space.  So, sharing an interface
because they ARE the same thing.

The fact that 50-70% (100 - 30-50% ;-) of the interfaces for each object
are the same indicates that they should be sharing something.

> Have you
> looked at the APIs defined in evms_plugfunc.h and evms_appAPIs.h?  You
> will see that each layer has different responsibilities and capabilities
> that do not overlap.  Do you really think that allowing nested partition
> managers would make the code simpler?

Yes.

> Pointing out problems in the current design is only going halfway.  For
> us to "move backwards" would require a complete, well thought out
> alternative which details exactly how all of the required function would
> be implemented.

Attached.  (Sorry for the C++... just it's a bit easier to show
inheritance in C++... I intend to write in C though ;-)

That said, it is nowhere near complete, and doesn't explain all
the functionality, etc.  But:

(1) the design you have now doesn't cover "everything" - although
I guess it does cover "required functionality"... but not if
I define that as allowing nesting :P  More importantly...

(2) I don't subscribe to the "think before you act" philosophy.  I
think doing gives you a much better understanding than thinking
(alone) does.  So, designs evolve, as they are implemented.

Also, I don't think it's clear that my design is/will be any simpler than
yours... although I think it has more "mathematical" elegance, which
doesn't mean it will be any easier to implement...

So, unless you are delighted by my design, I suggest you keep going
down the path you already have chosen.  I've changed my mind: I
think it could turn out that your way is easier/simpler (though I
still would like to believe it isn't... but that's because I like
nice abstractions, hehe)

It certainly is more obvious how to do it your way.

I'll keep working in my direction too, and we'll still help each
other out, hopefully ;-)  I think both designs should be explored
more, and we'll see where they lead...

> Not simply "collapse the layers".

Collapse isn't really the right word.  But see how there is
exactly one create() interface, for file systems, partition
managers, LVM, etc.?  (actually, I didn't sketch how
storage containers work, but they would be just another Feature...
I hope it's obvious from my mirroring example)

And exactly 2 resizes: because there are two types of resizes:
resize what you consume and resize what you provide.

And exactly 1 probe interface, etc.

This reflects "what's going on" better, IMHO, and looks pretty,
hehe.  As I said, I would like to think it simplifies things,
but there are still lots of questions to be answered (see my
comments in the design itself)

> We have discussed
> many ideas that sounded great when first brought forward, but upon
> deeper analysis proved inadequate or caused more problem than they
> solved.  Let me give an example:
> 
> "If you store metadata (name) in compatibility volumes like in EVMS
> volumes then persistent names become trivial in all cases."  
> 
> This is a true statement, and implementing it would indeed simply code
> and make name resolution easier; however it's not that easy.  As you
> pointed out, there are partitioning schemes which have no hidden/free
> space for us to store the name, so how do we actually implement this? 
> It sounded like a great idea, but just isn't feasible.

Right.

WRT to the IBM politics: forget my complaint... in reality, the bigger
problem is I haven't had time to read/discuss things (I don't think
I'm alone here...)  I do have time to do a lot more now though ;-)

Sorry for being so schizo!

> Agree 100%, which is why the smarts CAN'T be in the UI, they have to be
> in the Engine.  That sysadmin is not going to invoke a GUI on 1000
> machines, he is going to automate it using scripts, which is why the
> Engine should be 'smart' and the GUI (or other front end) dumb.

Aha.

Well, I think we should have a layering between the Engine and the
UI.  Sorry for not making this clear.

Basically: the Engine (IMHO) should represent "what's going on".
Then we have an intelligent layer that can analyses what's happening.
(This is where our complicated constraint solvers / searches happen)
And, the UI would probably talk to both layers.

But, again, I'm not convinced which way is better...

Just, I think having a low-level interface is a Good Thing TM.

> > So, second, the intelligence should be in the front-end.  It is
> > ridiculous to put a constraint-solver in the kernel.  Equally
> > ridiculous, IMHO, is to put things like "this argument is optional
> > - there is a default of XXX" in the kernel.  Putting UI information
> > in general is bad.
> 
> No. as stated above the smarts should not be in the front end, but in
> the common library (Engine).  

Well, I think there should be a low-level layer, and possibly a
higher-level "smart" layer.

The simple constraint solver in libparted is appropriate in the
low level bit, since it is really simple.  This only deals with
really low-level constraints, like alignment.

High-level constraints are things like: "I want to allocate A%
of space to X, Y and Z", etc.  That kind of high-level solver
(if we have one) should be a "layer above" the engine, IMHO.

(IMHO: the engine should merely be a low-level interface)

> Earlier you were criticizing us for rushing ahead with code, but now we
> don't have time to do a GUI properly?

Right ;-)  Full of paradoxes ;-)

Basically, my point is: people have tried this solution before, and
had problems.  Trying to solve those problems is hard, so you should
be weary of what you're get yourself into.  You'll probably need things
like relevance graphs, or something.  If you want to do "cutting edge"
UI research, then that's fine.  I'd love to too, if I had time.

Just don't expect to solve the problems in a reasonable amount of time.
Our main goal is storage, not UIs, so that's where we should spend
our "unreasonable" amount of time.

> I agree that there are many
> issues with a back-end driven GUI, but the alternative is to write GUI
> panels specific to every plug-in and to REQUIRE plugin writes to also
> write GUI panels.

It's not that hard to write GUI's...
Red Hat have written a GUI front end to libparted (somewhat incomplete)
in python, in about 500 lines.  Not a lot of work - probably
an equivalent amount of work to constructing relevance graphs, hehe.

Another option, BTW, is to accept that we will have a fairly bad
GUI... maybe people can live with it, for a while?  I think the
"hack up nice UIs in python" approach is nicer, though.  (I can hear
hch screaming from here - hch: if it makes you feel better, the
command-line one could be easily autogenerated...)

> Maybe we have a disconnect on exactly how dumb out UI is going to be. 
> This UI will be specific to storage management and will know about tasks
> such as volume creation, so it should be possible (simple?) to handle
> the scenario above.  What we are trying to hide from the GUI/cmdline is
> options which are not common to all plugins so that just because a new
> plugin has 1 extra option, we don't need to write a whole new GUI for
> it.

Where are we going to draw the line?

For example, file systems often haves LOTS of options, on creation.
Many of these are common (eg: block size)... so, file systems have
specific GUI code, but ext2 doesn't?

What about things like mirroring and encryption?  Do these have
there own hand-crafted GUI's?

BTW: I think the API you have is suitable for both automatic GUI
generation (except it doesn't do relevance constraints, etc.) AND
specific UIs.  You can build a smart UI on top of this protocol,
right?

Andrew