From owner-freebsd-hackers  Tue Nov 26 15:58:37 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id PAA09772
          for hackers-outgoing; Tue, 26 Nov 1996 15:58:37 -0800 (PST)
Received: from time.cdrom.com (time.cdrom.com [204.216.27.226])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA09767
          for <hackers@FreeBSD.org>; Tue, 26 Nov 1996 15:58:35 -0800 (PST)
Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.3/8.6.9) with ESMTP id PAA14279; Tue, 26 Nov 1996 15:51:18 -0800 (PST)
To: Joe Greco <jgreco@brasil.moneng.mei.com>
cc: peter@taronga.com, bmk@fta.com, brantk@atlas.com, hackers@FreeBSD.org
Subject: Re: Replacing sendmail 
In-reply-to: Your message of "Tue, 26 Nov 1996 16:34:25 CST."
             <199611262234.QAA17750@brasil.moneng.mei.com> 
Date: Tue, 26 Nov 1996 15:51:18 -0800
Message-ID: <14277.849052278@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

> CONFIGURATION of packages is a problem as well.  I am not sure that it
> is wise to try to solve both problems with the same tool, but am certainly
> willing to discuss it if you believe that it is (I will tell you now: I have
> a preconceived notion that it is not a good idea).

Well, I think we are all talking about much the same thing here,
simply with different jargon, so the ultimate design will probably
come down more to what the initial proof-of-concept looks like at this
stage than any long thread which debates the more etherial concepts of
configuration management.

However, just in closing, I'd like to also note that we should stay
focused on the fact that this is *not* being designed for hackers,
this is being designed for end-users, and the end users have become
conditioned by Windows & Macintosh machines to think in terms of
services rather than MTAs or packages or even UNIX subsystems.
Ultimately, the user doesn't want to think about "sendmail" or
"qmail", they want to think about "small mail agent" or "big mail
agent" (just to draw a very simplistic point of division - I'd expect
the real dividing line to be somewhat more complex).  They don't want
to know about lpr and optional filters, they want to say "I have a
printer, here's what kind it is, do the rest please!"

This is what makes me think that any framework will end up drawing
lines around things grouped by function, not by placement.

The traditional UNIX die-hards will also never accept a complete
decoupling of things like sendmail, so it's probably also not
practical to hope that you can "packagify" everything at the actual
implementation level - there will be a significant amount of
transparent bridge work going on in any real-life system which gets
developed.

						Jordan