Andrew Gaffney wrote:
> Eric Sammer wrote:
>> I'm not entirely sure what you mean by "real time" but the physical 
>> commands will be shelled out where required. If you're asking if we're 
>> going to reimplement fdisk in pure python, the answer is a certain 
>> "no." ;)
> 
> By real-time, I mean that if you create your partition layout in the 
> frontend and then click 'Next ->', it will fire off a function call to 
> the installer core which will put that partition layout into effect.

Aha. I see now. No, all action is delayed until all decision making is 
complete. This is for two reasons (one intended, one a nice side 
effect): 1. The front end is acting as just a special kind of install 
profile editor of sorts so teh backend is really the automated 
deployment part with some of the features missing. This makes for very 
good reuse of design / code. 2. Users like to experiment and a "Back" 
button is a nice comfort to newer users. Blowing away their partition 
table prior to all decisions being made might upset some folks.

> Just the same as most installers work, instead of how the GLIS frontend 
> and backend works.

Actually, as far as I know, most installers delay destructive actions 
even if they *say* they don't. Of course, I haven't looked at the code 
for any of these products recently, but it seems logical that if you 
performed a destructive operation such as altering a partition table 
*and* you provided a back button... well, I just don't know how you'd 
make that work in a reasonable, predictable, and safe fashion.

> With the frontend that Scott Hadfield and I jointly 
> wrote for GLIS, the frontend creates the config file which gets passed 
> to the backend when the config is done. That is not real-time.

Right. This will function in a similar manner. I think this is a better 
design than firing off each part piecemeal.

> Everybody is repeating themselves, even me. ;)

It's good for all the stuff it's good for.

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