[gentoo-installer] Some clarifications and a plea

[Eric Sammer]

I wanted to clarify some of the things in the last few emails because I 
think a few things are happening. These include, but are not limited to, 
people assuming certain implementation details, implementation being 
focused on too tightly, and a lack of reading (or rereading) some of the 
documentation.

To clarify the front end / back end discussion...

The "front end" and "back end" are just terms used to describe two 
different sections of code. They are NOT two different applications. 
They are NOT a client and server. They are the SAME executable package 
meaning that no IPC method such as pipes be used to communicate between 
them. They are the same code. Normal method calls can be made between 
them. If need be, we'll change all references to front end and back end 
to "code base." There is one application, one API and they are the same 
thing. People are getting hung up on the idea that they are separate or 
two independent "things" that need to "communicate." They aren't. No XML 
messages or pipes are used, just plain old fashioned python method calls.

To clarify XML vs. object representation of data...

XML is used ONLY for the format of serialized files in the installer. 
There's no XML messaging, passing of XML, or XML "stuff" going on in the 
installer. There are objects (classes) that represent the parsed form of 
  an XML file. This is a data object and both GLIArchitectureTemplate 
and GLIInstallProfile are good examples of this. When the installer 
needs to load a profile, it creates a new GLIInstallProfile, calls 
object.parse("/path/to/file.xml"); and all data is parsed and stored in 
instance variables in the GLIInstallProfile object. The XML that was 
parsed in memory disappears and goes away. It's not needed anymore. We 
can pass the GLIInstallProfile object around to different classes in the 
installer (this how user selections are "passed" between the front end 
and back end, if I dare say so) as a solid collection of all options. It 
could be incomplete, it could be complete - don't worry too much about 
it. When all choices are made IF the user wants to be able to recreate 
the installation, they can opt to serialize GLIInstallProfile back to 
XML. This is entirely separate from installation, passing of data, etc. 
and doesn't matter. It's a separate action. XML is just a file format in 
our case, not a messaging system. The object representation form of the 
profile is a regular python object - not an XML stream or anything that 
has to be parsed.

If you have "partial" installs or whatever broken wackiness we want to 
try and accommodate, you simple don't fill in everything in the 
GLIInstallProfile and the back end won't do it (don't worry too much 
about it - it WILL get figured out and is mostly just implementation 
talk about a system with no implementation yet). There's no "feeding XML 
to the back end" or other such things. There is nothing in the design 
that will prevent manual intervention, or other things.

To clarify the immediate action vs. postponement of all actions until 
the user has selected all options discussion...

Yes, you will be able to do it. No, not initially. Yes, the current 
design will allow for its addition in a simple and efficient way.

I understand that no one trusts the installer yet. There's no reason to 
- there's no code. That also means there's no reason to distrust it 
either. If people want to do things manually, that's great, but I'd 
rather make sure there's no *reason* to do so. Rather than figure out if 
you will be able to (and you will, I promise) please tell us what you 
want to do that just (seemingly) can't be done given a user interface 
(and don't revolt - a plain text interface is still a user interface) 
with proper options.

I promise you'll be able to...

- define your own custom steps
- use your own special commands in custom steps and default steps
- write your own special arch templates (see previous item)
- write profiles by hand without using any user interface other than vi 
(emacs won't be compatible, mind you)
- load and save profiles for later use
- run commands atomically OR after each step
- do whatever voodoo you want to do by hand between steps

As much as I hate to say it (again), this is all covered in the docs 
that were written, as well as the two diagrams. So, that URL again is:
http://www.gentoo.org/proj/en/releng/installer/

-- 
Eric Sammer
Gentoo Linux
http://www.gentoo.org