Re: [gentoo-installer] Some clarifications and a plea

[Andrew Gaffney]

Eric Sammer wrote:
> 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.

I was under the impression that the "back end" was going to be written in such a way that 
it allowed for the creation of different frontends, not necessarily written in the same 
language as the backend (Python in this case). This is the GLIS way. Although, this idea 
may have just come from a discussion I had with Nathaniel.

> 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.

This all stems from the idea of separation of FE and BE, which in my opinion (not that it 
counts for anything), is a good thing.

> 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/

I don't think that anyone is *really* reading that ;)

-- 
Andrew Gaffney
Network Administrator
Skyline Aeronautics, LLC.
636-357-1548


--
gentoo-installer@g.o mailing list