Date: Sun, 05 Jul 1998 12:01:28 -0700 From: Mike Smith <mike@smith.net.au> To: Garance A Drosihn <drosih@rpi.edu> Cc: Mike Smith <mike@smith.net.au>, hackers@FreeBSD.ORG Subject: Re: Variant Link implementation, continued Message-ID: <199807051901.MAA00406@antipodes.cdrom.com> In-Reply-To: Your message of "Fri, 03 Jul 1998 01:40:56 EDT." <v04011722b1c21a42b8e0@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807051901.MAA00406>