From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14902 invoked from network); 3 Feb 2004 10:37:58 +0000 Received: from smtp.gentoo.org (128.193.0.39) by eagle.gentoo.oregonstate.edu with DES-CBC3-SHA encrypted SMTP; 3 Feb 2004 10:37:58 +0000 Received: from lists.gentoo.org ([128.193.0.34] helo=eagle.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.24) id 1AnxwL-0001gS-NO for arch-gentoo-installer@lists.gentoo.org; Tue, 03 Feb 2004 10:37:57 +0000 Received: (qmail 3786 invoked by uid 50004); 3 Feb 2004 10:22:43 +0000 Mailing-List: contact gentoo-installer-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail Reply-To: gentoo-installer@lists.gentoo.org X-BeenThere: gentoo-installer@lists.gentoo.org Received: (qmail 31919 invoked from network); 3 Feb 2004 10:22:43 +0000 From: Paul de Vrieze To: gentoo-installer@lists.gentoo.org Date: Tue, 3 Feb 2004 11:22:39 +0100 User-Agent: KMail/1.6 References: <401E4DAB.8030409@skylineaero.com> <401F1986.3020607@skylineaero.com> <401F1FF9.2000405@gentoo.org> In-Reply-To: <401F1FF9.2000405@gentoo.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200402031122.41139.pauldv@gentoo.org> Subject: Re: [gentoo-installer] a few different questions X-Archives-Salt: 1320b1c1-3ba4-43b1-bb10-5d0b8b6a0481 X-Archives-Hash: 24bf2885f06896d65add48b8d3691a79 =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 03 February 2004 05:13, Eric Sammer wrote: > > 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. One could offer an option to force the actions to be done. It would be=20 needed when users perform manual actions (but not in all cases). Of=20 course forcing actions will disable the back button so probably warrants=20 a warning. > > > 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. It is the task of the frontend to either save up the actions or to send=20 them to the backend immediately. As long as the backend can perform=20 actions as soon as they are received (incomplete xml file) the backend=20 can handle whatever you want. Paul =2D --=20 Paul de Vrieze Gentoo Developer Mail: pauldv@gentoo.org Homepage: http://www.devrieze.net =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAH3ZvbKx5DBjWFdsRAoWcAJ4xW6dh9D4w6in+flp0ws5nPkg5QwCgtQaS DZopM4VszYS5hGYQiKX4acQ=3D =3DDn/z =2D----END PGP SIGNATURE----- -- gentoo-installer@gentoo.org mailing list