From owner-freebsd-config Fri Apr 24 10:07:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA04420 for freebsd-config-outgoing; Fri, 24 Apr 1998 10:07:50 -0700 (PDT) (envelope-from owner-freebsd-config@FreeBSD.ORG) Received: from xmission.xmission.com (softweyr@xmission.xmission.com [198.60.22.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA04332 for ; Fri, 24 Apr 1998 10:07:31 -0700 (PDT) (envelope-from softweyr@xmission.xmission.com) Received: (from softweyr@localhost) by xmission.xmission.com (8.8.8/8.7.5) id LAA04969; Fri, 24 Apr 1998 11:07:25 -0600 (MDT) From: Wes Peters - Softweyr LLC Message-Id: <199804241707.LAA04969@xmission.xmission.com> Subject: Re: Config Databases To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Fri, 24 Apr 1998 11:07:25 -0600 (MDT) Cc: config@FreeBSD.ORG In-Reply-To: <4474.893404047@time.cdrom.com> from "Jordan K. Hubbard" at Apr 24, 98 00:47:27 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-config@FreeBSD.ORG Precedence: bulk > Right. I'm not saying that this behavior is ideal, far from it, I'm > simply saying that this is the lowest-impact approach and will require > the least programming headache. And, please note, it *is* consistent with current practice. If you enter a bogus password entry with vipw, it gets put in the file, but the user *still* won't be able to login. > Unless we're all just discussing this > as an intellectual exercise, of course, and there's no intention of > actually implementing it in which case by all means let's discuss all > the errors one might pass back on close() in hopes that the > application will even check the return value. :-) Well, vi will at least. That saves us in the 'viconfig' case. ;^) The only granularity you really *need* is 'OK, it worked' vs. 'ERROR, something was wrong.' > Succeeding silently and using secret knowledge of the file format to > tack in comments also strikes me as a cute but ultimately untenable > workaround, so I really do vote for the simpler approach. The 'odm database' in AIX uses the approach, and it is helpful, but it costs them a lot of programmer time to develop and maintain their import programs. Bleh. Jordan's right (as usual): get it working, then embellish it later. I suggest starting off with one simple database, something simple like /etc/services, and getting IT working, then adding other databases. This has the advantage of being able to dole out addition of various databases to a fairly wide range of people once the initial framework is in place. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.xmission.com/~softweyr softweyr@xmission.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-config" in the body of the message