Skip site navigation (1)Skip section navigation (2)
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>