Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!mit-eddie!ll-xn!ames!oliveb!sun!pepper!cmcmanis
From: cmcmanis%pepper@Sun.COM (Chuck McManis)
Newsgroups: comp.sys.amiga
Subject: Re: ENV: variables (long)
Message-ID: <70139@sun.uucp>
Date: 26 Sep 88 17:32:54 GMT
References: <374@uwslh.UUCP> <5660014@hpcvca.HP.COM> <2629@sugar.uu.net> <4781@cbmvax.UUCP> <933@tragicomix.liu.se>
Sender: news@sun.uucp
Reply-To: cmcmanis@sun.UUCP (Chuck McManis)
Organization: Sun Microsystems, Mountain View
Lines: 28

First Randell wrote :
>	I'd greatly prefer it if people would use subdirectories (ex:
>"Setenv foobar/width 10", "dir env:foobar".)

Then in article <933@tragicomix.liu.se> (Mike Henry) writes:
> Is this really an EFFICIENT idea ?? Please consider this:  The example
> "Setenv foobar/width 10" will open a file "width" in the directory
> "foobar" with nothing more in it than the two characters "1" and "0"
> (well of course we get "\0" too, so make that three). How much space
> have we used to get a file that will hold just three characters ?? I
> smell a waste of space here, or have I missed something ??

Well you have missed a couple of things. One in terms of search speed for
the variable you want it is *very* efficient. That is because the Amiga's
filename hashing algorithim can find files very quickly, probably as quickly
as a shell could looking through it's own linked list. Secondly, while at
the moment they are implemented as files on the assigned device what CBM
has done is define the semantics for them. This is important, now the 
underlying mechanisim can be rewritten to increase the storage efficiency.
In fact, one could probably whack Matt's ram-disk handler to do just that
with a minimum of fuss and a maximum of efficiency. I could concievably
enforce local variables by keying off the reply port for the packets that
were sent to it. 


--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.