1 |
I wanted to clarify some of the things in the last few emails because I |
2 |
think a few things are happening. These include, but are not limited to, |
3 |
people assuming certain implementation details, implementation being |
4 |
focused on too tightly, and a lack of reading (or rereading) some of the |
5 |
documentation. |
6 |
|
7 |
To clarify the front end / back end discussion... |
8 |
|
9 |
The "front end" and "back end" are just terms used to describe two |
10 |
different sections of code. They are NOT two different applications. |
11 |
They are NOT a client and server. They are the SAME executable package |
12 |
meaning that no IPC method such as pipes be used to communicate between |
13 |
them. They are the same code. Normal method calls can be made between |
14 |
them. If need be, we'll change all references to front end and back end |
15 |
to "code base." There is one application, one API and they are the same |
16 |
thing. People are getting hung up on the idea that they are separate or |
17 |
two independent "things" that need to "communicate." They aren't. No XML |
18 |
messages or pipes are used, just plain old fashioned python method calls. |
19 |
|
20 |
To clarify XML vs. object representation of data... |
21 |
|
22 |
XML is used ONLY for the format of serialized files in the installer. |
23 |
There's no XML messaging, passing of XML, or XML "stuff" going on in the |
24 |
installer. There are objects (classes) that represent the parsed form of |
25 |
an XML file. This is a data object and both GLIArchitectureTemplate |
26 |
and GLIInstallProfile are good examples of this. When the installer |
27 |
needs to load a profile, it creates a new GLIInstallProfile, calls |
28 |
object.parse("/path/to/file.xml"); and all data is parsed and stored in |
29 |
instance variables in the GLIInstallProfile object. The XML that was |
30 |
parsed in memory disappears and goes away. It's not needed anymore. We |
31 |
can pass the GLIInstallProfile object around to different classes in the |
32 |
installer (this how user selections are "passed" between the front end |
33 |
and back end, if I dare say so) as a solid collection of all options. It |
34 |
could be incomplete, it could be complete - don't worry too much about |
35 |
it. When all choices are made IF the user wants to be able to recreate |
36 |
the installation, they can opt to serialize GLIInstallProfile back to |
37 |
XML. This is entirely separate from installation, passing of data, etc. |
38 |
and doesn't matter. It's a separate action. XML is just a file format in |
39 |
our case, not a messaging system. The object representation form of the |
40 |
profile is a regular python object - not an XML stream or anything that |
41 |
has to be parsed. |
42 |
|
43 |
If you have "partial" installs or whatever broken wackiness we want to |
44 |
try and accommodate, you simple don't fill in everything in the |
45 |
GLIInstallProfile and the back end won't do it (don't worry too much |
46 |
about it - it WILL get figured out and is mostly just implementation |
47 |
talk about a system with no implementation yet). There's no "feeding XML |
48 |
to the back end" or other such things. There is nothing in the design |
49 |
that will prevent manual intervention, or other things. |
50 |
|
51 |
To clarify the immediate action vs. postponement of all actions until |
52 |
the user has selected all options discussion... |
53 |
|
54 |
Yes, you will be able to do it. No, not initially. Yes, the current |
55 |
design will allow for its addition in a simple and efficient way. |
56 |
|
57 |
I understand that no one trusts the installer yet. There's no reason to |
58 |
- there's no code. That also means there's no reason to distrust it |
59 |
either. If people want to do things manually, that's great, but I'd |
60 |
rather make sure there's no *reason* to do so. Rather than figure out if |
61 |
you will be able to (and you will, I promise) please tell us what you |
62 |
want to do that just (seemingly) can't be done given a user interface |
63 |
(and don't revolt - a plain text interface is still a user interface) |
64 |
with proper options. |
65 |
|
66 |
I promise you'll be able to... |
67 |
|
68 |
- define your own custom steps |
69 |
- use your own special commands in custom steps and default steps |
70 |
- write your own special arch templates (see previous item) |
71 |
- write profiles by hand without using any user interface other than vi |
72 |
(emacs won't be compatible, mind you) |
73 |
- load and save profiles for later use |
74 |
- run commands atomically OR after each step |
75 |
- do whatever voodoo you want to do by hand between steps |
76 |
|
77 |
As much as I hate to say it (again), this is all covered in the docs |
78 |
that were written, as well as the two diagrams. So, that URL again is: |
79 |
http://www.gentoo.org/proj/en/releng/installer/ |
80 |
|
81 |
-- |
82 |
Eric Sammer |
83 |
Gentoo Linux |
84 |
http://www.gentoo.org |