Path: utzoo!utgpu!watmath!att!tut.cis.ohio-state.edu!cs.utexas.edu!sun-barr!newstop!sun!pepper!cmcmanis
From: cmcmanis%pepper@Sun.COM (Chuck McManis)
Newsgroups: comp.sys.amiga
Subject: Re: CD storage (was No more Cinemaware stuff for Amiga !!!????)
Message-ID: <121658@sun.Eng.Sun.COM>
Date: 15 Aug 89 22:03:47 GMT
References: <346@eagle.wesleyan.edu> <1523@ndmath.UUCP> <514@morgoth.UUCP> <121390@sun.Eng.Sun.COM> 
Sender: news@sun.Eng.Sun.COM
Reply-To: cmcmanis@sun.UUCP (Chuck McManis)
Organization: Sun Microsystems, Mountain View
Lines: 44

In a previous article (Jonathan D. Trudel) writes:
->Define slow for me.  I saw such a system set up on an IBM pc that 
->my girlfriend's friend's husband was working on for a company down in
->the DC area (I don't remember the name of the company) and they are
->offering such a product as the one you describe.  They are putting
->governmental records onto an optical disk and getting really reasonable
->data recovery from it.  Considering that it replaces the previous
->microfiche technology, the access time is greatly improved.  The only
->slowdown occurs for printing - normal photocopy processes are an order
->of magnitude faster than laser printing...

Ok, my comment was that building the index was "slow", an operating CD
ROM system is certainly "fast" by most definitions. Using your example,
how are the records indexed? If they are simple keys like last names,
or days of the week then you can build the index algorithmically and 
fairly quickly. If they are based on things like "All references to 
the FUJI project that involved funding decisions" which is the type of
query one might like to make of the congressional record, someone has
to read all of the text and make those connections manually. When an
index is built that way, it can take months or years to do. Similarly,
if you collected a whole bunch of stuff that was externally related like
all of the Fish Disks, you get one index for free "find by VOlume #" 
but have to manually build the "find all demos, find all editors, etc"
indexes by hand. Once these indexes have been built and the CD has been
mastered, and a production CD is available. *Using* the data is very 
quick and convienient.

->I think that for many data retrieval applications that the access time I
->saw in such a system was within reason.  GRanted, we work with
->high-speed computers all day long, but many people don't, and are
->willing to put up with what we might perceive as slowness.  But then
->again, isn't that what people said about computers 20 or 30 years ago?

For systems where you are watching an animation and the outcome of the
animation is dependent on which parameters you set, the several possible
outcomes need to be physically close because they must be recalled and
decompressed in less that the time between when the first one was started
and when it finishes. For just getting records, retrieval times on the 
order of 1 second aren't bad at all. 

--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.
"A most excellent barbarian ... Genghis Kahn!"