From owner-freebsd-hackers Sat Jul 4 18:42:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA06247 for freebsd-hackers-outgoing; Sat, 4 Jul 1998 18:42:09 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles321.castles.com [208.214.167.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA06168 for ; Sat, 4 Jul 1998 18:42:00 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id MAA00679; Sat, 4 Jul 1998 12:31:58 -0700 (PDT) Message-Id: <199807041931.MAA00679@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: sthaug@nethelp.no cc: drosih@rpi.edu, hackers@FreeBSD.ORG Subject: Re: Variant Link implementation, continued In-reply-to: Your message of "Sat, 04 Jul 1998 10:58:51 +0200." <28706.899542731@verdi.nethelp.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 04 Jul 1998 12:31:58 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Aren't you simply reinventing VMS logical names & tables here? > If you were following this discussion last time, you would have the background on where we overlap and differ. Basically, we are faced with a large parameter space, and the need to present 'views' of this space varying with context. Right now, the space is fragmented along storage/access boundaries, with sections grown on an ad-hoc basis as required for their immediate consumers. What we are seeing now is a growing number of situations where consumers need to access parameters from multiple spaces, and are being confronted with numerous problems stemming from the nature of implementation of these separate fragments. For example, the variant link decoder really wants to be able to key a link off many things, but in the specific context or 'view' of the process for whom the link translation is being made. The link may want to draw on parameters that are traditionally stored in the process' environment (or that of its parents), or on parameters stored in the sysctl database, or others again. This is the same basic problem that led Apollo, Digital and many others to look at a single, unified parametric store. To grow, we need to do this as well. We have a lot of other peoples' experience to learn from, not to mention bicker about. 8) -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message