From owner-freebsd-hackers Sun Jul 5 23:31:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA12441 for freebsd-hackers-outgoing; Sun, 5 Jul 1998 23:31:15 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles137.castles.com [208.214.165.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA12434 for ; Sun, 5 Jul 1998 23:31:10 -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 MAA00406; Sun, 5 Jul 1998 12:01:28 -0700 (PDT) Message-Id: <199807051901.MAA00406@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Garance A Drosihn cc: Mike Smith , hackers@FreeBSD.ORG Subject: Re: Variant Link implementation, continued In-reply-to: Your message of "Fri, 03 Jul 1998 01:40:56 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 05 Jul 1998 12:01:28 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > At 9:16 PM -0700 7/2/98, Mike Smith wrote: > > Allowing links to indicate that they *should* be keyed off the > > environment space, OTOH, isn't such a sin. eg: > > > > ${sysctl:hw.arch} and ${env:USER} > > > > but this creates a new union space with yet another different > > syntax. > > > > ${space=sysctl, mib=hw.arch} and ${space=env, var=USER} > > > > perhaps? > > Hmm, not quite the strategy I was leaning towards, but I do feel > much less concerned with this than the earlier alternative. If > the creator of the link really *wants* the link to change based on > an environment value, then any headaches caused are their fault, > and not the implementation's fault. More to the point, the variant link should be allowed to key off more than just values in the environment space. > I must admit I don't understand your comment about a "new union > space", so I would lean toward a more terse syntax, such as your > first suggestion. Perhaps that just proves I should go home and > get some sleep... You need to look at the issue of parametric information from a very broad perspective. You can consider parametric information as an identifier and a value, and these parameters live in "parameter space", ie. the set of all parameters (this is basically the same as "tuple space"). At the moment, this space is segregated into lots of little separate spaces (eg. the parameters in /etc/rc.conf, DNS, /usr/local/etc/rc.d and so on). Each of these subspaces have different naming conventions, different access methods, etc. By allowing the variant symlink implementation to use parameters from more than one subspace, we create a new space which is the union of these separate subspaces. Because we now transcend the naming conventions for each of these subspaces, we need a new naming convention that provides the extra identification information. The danger in coming up with a new "just good enough" naming convention is that it's _yet_another_ naming convention that's incompatible with everything else. -- \\ 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