| 1 |
All -- |
| 2 |
|
| 3 |
A good discussion was just had on the IRC channel and I thought I'd |
| 4 |
summarize it here for anyone who missed it. |
| 5 |
|
| 6 |
A suggestion (which has come up before in other discussions) was made to |
| 7 |
think of the installer as two separate pieces. A front end and a back end. |
| 8 |
The front end would be nothing more than a highly specialized text editor, |
| 9 |
responsible for interfacing with the user in some fashion and outputting a |
| 10 |
text file in some standards-based format (XML was favored among those in |
| 11 |
the discussion) |
| 12 |
|
| 13 |
The back end would be responsible for taking this file and doing the actual |
| 14 |
installation. The back end would then spit out messages in some |
| 15 |
pre-defined format that some other app (not necessarily the front-end, but |
| 16 |
it could be) could listen to and use to display status messages to the |
| 17 |
user. |
| 18 |
|
| 19 |
By separating the two pieces as such, we ensure that people can have *any* |
| 20 |
front end that they want. Want a GTK installer? no problem. QT? OK. |
| 21 |
Prefer a web-based installer? You got it. In other words, as long as the |
| 22 |
front end spits out the file in the format expected by the back end, |
| 23 |
nothing else matters. The two pieces are entirely abstracted from one |
| 24 |
another (This is covered in the requirements doc that Eric has been |
| 25 |
maintaining. We just fleshed it out a bit on IRC) |
| 26 |
|
| 27 |
A further discussion was made about having the back end spit out status |
| 28 |
messages of some sort that could be parsed by another program and used to |
| 29 |
display progress updates as the install progresses. Again, it was |
| 30 |
suggested that these be standards-based (again, XML was favored among those |
| 31 |
in the discussion) so that it would be easy to tie them into other |
| 32 |
applications. |
| 33 |
|
| 34 |
With the above described installer, you could have both: |
| 35 |
|
| 36 |
* an interactive installer that used a GUI interface to walk a user through |
| 37 |
installing his first Gentoo system from scratch |
| 38 |
* an automated installer that installed gentoo on a 200-node web cluster |
| 39 |
and displayed the status of all 200 installations on one web page that |
| 40 |
the admin could quickly scan to note the progress of each install. |
| 41 |
|
| 42 |
Abstracting things this way also allows us to do other cool things like |
| 43 |
have a web site that creates installation files for users that they can |
| 44 |
download and use to install Gentoo. Or, ISPs could allow their customers |
| 45 |
to install Gentoo remotely while still giving them total control over the |
| 46 |
install process, including custom partition schemes, CFLAGS, etc. |
| 47 |
|
| 48 |
Doing things this way is in-line with Gentoo as a distribution -- we give |
| 49 |
users the flexibility and choice to do things the way they want/need to. |
| 50 |
|
| 51 |
So, thoughts? |
| 52 |
|
| 53 |
--kurt |
Archives