Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga
Subject: Re: statement
Message-ID: <8612160732.AA06465@cory.Berkeley.EDU>
Date: Tue, 16-Dec-86 02:32:48 EST
Article-I.D.: cory.8612160732.AA06465
Posted: Tue Dec 16 02:32:48 1986
Date-Received: Wed, 17-Dec-86 04:54:25 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: University of California at Berkeley
Lines: 53

>> The icons could be speeded up by putting them all in one file in each
>> directory...or in a great big file in the root directory.  Then you
>> could write utilities to install, copy and delete icons.  A file that
>> didn't explicitly have an icon definition in the "icon file" would be
>> given a default "vanilla" icon, sort of what the Mac does for files it
>> has no specific definitions for.
>
>Sorry to disappoint you, however, this would only work if it was the
>*first* file you wrote to the disk and you never changed it. Since
>AmigaDOS uses a hashing scheme to locate directory entries it has
>no compunction about putting directory blocks close together. Thus
>your "one file" may have pieces of itself all over the disk. A somewhat
>better approach might be to have an "icon pointer" in directory blocks
>that points to a linked list of icon file headers in that directory. 
>This would at least prevent you from having to scan the entire directory
>for .icon files. (There are even free longwords in the Directory block 
>and the FileHead block structures, how about it Andy 1.3?) 

Sorry to disappoint you, but the one-file scheme would be extremely
effective especially when compared to the 'search the entire directory and
read all the info files' scheme.  For one, both schemes read exactly the same
information (thus your argument falls to the four winds).  The whole point 
is to get rid of the idiotic directory searching.

and your comment on about the hashing function doesn't apply at all... it
doesn't really matter if it's the first file or not, just as long it is
a known file.  The new scheme would use a known file name and thus a known
hash and for all practical purposes a single seek to get to the base block 
for the entire folder.   Compare this to having to open each X.info file
in the current scheme... one for each ICON.

>> As it is, the current Workbench has enough holes in it that I would
>> label it as unsuitable for the novice user.
>> Mike Portuesi
>
>I wouldn't label it unsuitable, it has improved alot in 1.2 and I assume
>it will do so even more in 1.3. I hacked together an interface for the
>Lattice 3.1 C compiler that ran under workbench and it seemed to work
>out fairly well. Now that some of the tools like Egad! are coming together
>you should probably be on the lookout for better workbench applications.

I would label it completely unsuitable... and for one reason only: It's
too slow.  You've talked a lot about it being 'better under 1.2'.  Well,
I've been using 1.2's specific workbench improvments for the past couple
of months (it was in beta 4 ,all later betas, and probably some earlier
versions as well), and frankly, the speed up is only somewhat noticeble.
You don't seem to understand that placing everything in a single file per
folder would be at least an order of magnitude faster (read 10x), if not
more.



								-Matt