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