From owner-freebsd-hackers Sun Nov 30 22:47:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA11906 for hackers-outgoing; Sun, 30 Nov 1997 22:47:25 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA11897 for ; Sun, 30 Nov 1997 22:47:21 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id WAA20038; Sun, 30 Nov 1997 22:47:06 -0800 (PST) To: Alex cc: "hackers@freebsd.org" Subject: Re: Out of Box experience (Was: Re: How is selection made of what goes into CDrom?) In-reply-to: Your message of "Sun, 30 Nov 1997 22:43:09 PST." Date: Sun, 30 Nov 1997 22:47:06 -0800 Message-ID: <20034.880958826@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > What about making some of the basic sysinstall (or whatver) functions into > a shared library, rpm and librpm come to mind. That way a command line > based installer could add its own menu on top of that, and a GUI one could > add it's own thing on top of that. Plus, it would have an advantage of > seperating the UI and "low-level" stuff somewhat, so that bugs in one, > wouldn't necesarily force a re-compilation of the other. You can break this problem at any number of points, be it front-end/back-end, producer/consumer or message based with the UI running as a separate process. :-) However you choose to handle the complexity of multi-UI installer, it's not something you can just bang together in a weekend and that's the real problem. Conceptual models we have *plenty* of. The time to execute them, almost *none* of. :-( Jordan