€€²³

		Virtual Work Space or Virtual Work Bench

Ã *!ÃA PROJECT PROPOSALƒ
Ã *#Ãby Anselm Hookƒ
Ã *%ÃJuly 2 1987ƒ
Ã *%ÃJan 2 1991ƒ

	Are you one of those people who has masses and masses offloppys? And doesn't know² "quite for sure"³ which floppiescontain duplicates or more recent versions of files?

	If you're like me you probably rely on the ²"things alwaysget bigger"³ human axiom to find the most recent version of somefile that you are working on.  And you probably apply a ²"its forsure in the next archive"³ algorithm to finding that file.

	Well we all know about these little human folibles.  But WhyI ask, don't we let the computer take care of all this?  By thisI mean not a disk manager or some such unworkable oddity, but a”"virtual"• enviroment, a kind of ”"super workbench"• whereeverything appears to be visible at one time, ²even if it inarchive³ or off on some floppy somewhere.  And your mentalanguish is reduced merely to finding the correct disk - as agreedupon between the computer and yourself by some simple numberingscheme - rather than trying to decide if the disk you did find isright after all.

	Now hopefully you'll agree with me that a Virtual Work Spacewould be a "cool neato" thing to have, and probably fantasticallyuseful.  And probably you'll say "gee why didn't somebody thinkof that before?".  But what about all us poor unfortunate misfitswho have already buried ourselves in a massive landslide of 3 1/2inch floppies, bernoullis, syquests and suchlike?  What hope isthere for us?  Are we forced to fling out our wonderful solutionto the younger generation and exclaim "go on without me!?"

	Luckily perhaps not!  If we were very good softwaredesigners we would make our Virtual Work Space in such a way thatit not only maintained this representational enviroment, butcould actually unsnare the gordian knot we've wound ourselvesinto.

	The humble scheme which I submit for your approval hasthree parts, the virtual workspace I've already mentioned, theidea of a "flat" workspace which i briefly touched upon when Iused the word "archive" above (and will clarify later), andfinally and most importantly the idea of automatic collation andsorting which I will now gracefully step into.


Üj      ÜŒ	Each disk or harddrive "known" by the system would have aphysical number associated with it.  This number would be givenout by the Operating system and would be unique to every disk andevery instance of the Virtual System itself.  For example if twofriends each had a copy of the virtual system running, and theyboth shared access to a bernoulli, the bernoulli disks would beknown by different numbers on each system.  The number would be acomposite of an absolute ID (this part would be shared by bothsystems) and a system specific ID (probably the users orcomputers personal name).

	A user could access some media directly, or the user couldspecifically ask their system to "consume" the media; to build upa mental image of that media's contents, and to check forredundancies against any of its previously established memories(retained in a mega-database somewhere in *active* mediareserves).

	When the system consumes the contents of some media (likedf0: dh0: di0:...) it does some very special things.  It collectsall the superficial information about a file that it can, thefiles name, any comments, any datestamp, the file size, perhapseven the files physical block addresses on the media, the mediafrom whence it came.  As well it builds up a series of checksumsfor every 256 bytes or so (depending on the file size) as well asa very unique extra-long master checksum using some kind ofunlikely-to-be-repeated cyclic-redundancy-checksum scheme (CRC).

	If the media has no files (for example a game like VORTEX)then it just knows the entire disk as a single thing, and perhapsbuilds up some original information for the entire media as well.

	As well the Operating System will attempt to perform a"whatis" on files, trying to penetrate archives, and determinethe nature of particular files (such as IFF, LZW, TIFF, RIFF,ANIM, ARC, ZOO, WARP).  It will treat the contents of an archiveas individual files, however should retain the relational linkageto their owner.

	Once it has built up all the information about the files itthen searches its mega-database for any duplicate instances; asverified by the master checksum.

	Additionally by using the sub checksums it performs  acoarse "difference" on all the fledgling files.  The "diff" isused to check for more-recent files (based on the infamous"things grow" axiom) and as well it checks for link-viruses.

	The user can now enter his Virtual Work Space and see thismedia presented there.  The user may enter the particular mediaand see all the files therein.  If the files are duplicates offiles elsewhere on the system then they will graphically flash,or whatever.
Üj      ÜŒ	If a file is more recent or at least somehow related tosome file already in the mega-database then it also appropriatelystands out.

	Now comes the fun part!  The user can move the files aroundin their virtual enviroment, making their enviroment look*exactly* the way they want, without actually shuffling filesaround on the physical media. Yet when a file has to execute, orcall upon resources the process of connecting the human usersmental linkages to physical media localities is handledflawlessly by the low levels of the operating system.  Possibly
asking the user for a certain numbered disk if that is required.

	Let me just finish up the idea of Flat before I gotogeneral caveats.

	Flat means that everything is perceived to exist at the samelevel in the virtual space, the user can operate on a file,read/write/edit/delete regardless of if it is in archive or not. The system may mention to the user that the file is going to bere-archived so that the user can abort the procedure if they arein a hurry (and just store the file uncompressed) [of coursefiles that are not normally in archive remain de©archived].

	There are some caveats:

	When adding a new disk you and the computer must agree to a
number for that disk, the computer will suggest a number, basedon the datestamp, unique properties of the disk, the computersname or your name and suchlike.  You must then physically writeupon the disk the number to which you have both agreed.  In thisaspect the Operating system does act like a disk manager - but tosay that is to deny its real application.

	The process of building up the mega-database is probablygoing to be painfully slow, but you probably simply can't evenconceive of just how much time you waste otherwise.  And incomparison to that it is blazingly fast.

	The system probably would feel most at home on a hard-drive,from whence its probing tentacles could safely extend.   Diskusers would certainly have to have at least one drive where themaster-disk could always sit such that the mega-database could beupdated safely.

	There isn't any reason why the mega-database couldn't bebroken up into smaller segments (or duplicate instances such asin a network).

	The Virtual Work Space should be able to allow the user towork with any special format in a modular way, there should be anIFF viewer on tap, editors (like ED, CED, HED, WP) and variousarcers and de-arcers.
Üj      ÜŒ	The Virtual Work Space exists at a low level of the diskoperating system.  It would physically just be another RAM: likedevice, except much more magical.  There is a visible front endjust used to say "consume" possibly inside and along with atoolspace like the "NeXT" features.

	To round out the package there should be special support forthings that are irritating currently.  Such as proper archivalbackup, where each floppy or media subset of an archive containsa holographic image of the contents of the entire archive - suchthat the entire archive isn't lost for lack of disk #1!

	As well the enviroment should be able to tell you where the
*largest* files are anywhere (how often have you picked your waythrough Quarter Back trying to find and deselect the largestfiles?).

	And of course when you buy your Floptical Read/Write (orHoloStore!) you can ask the system to transfer to your new systema real copy of everything which perfectly mimics your virtualcopy.  Then you can make an extremely large bonfire and burn allyour old disk gleefully, without the slightest nagging doubt.

	This system has some very nice advantages, mostly just arecap of the three prime features:
À
JJÀ
1) Virtual - blast through the bottleneck of physical
   media, physical localities.

2) Organizational - solve your hair-pulling disk
   sorting anguish forever!

3) Flat - archives are just another form of locality,
   bring the file contents up to the virtual level as
   well.

ÀJ
JÀ
A couple of other features:

	There is the archival backup as I mentioned before,basically anything better than what is out there already will dovery well.  I imagine a kind of automated backup archival systemwith a smarter disk format organization (holographic image ofdirectory of all disks on each disk when possible).

	There should be a full complement of Norton Utilities typedisk tools to go with the package.

	There is the toolspace of course, which allows access tocommonly used tools, a'la NeXT, and access to special functionsin the virtual device.

	There will be media backup, ie: copyprotected media etc...
Üj      ÜŒ
Some Mildly Technical Comments:

	The system consists of two parts:

 	1) a device driver visible to the CLI and WORKBENCH as a
 	   device very much like RAM:

	2) a "toolspace" exactly like on the NeXT which progresses
	   down the right or left side of the screen and stores
	   whatever frequently used scripts and executables that
	   the user wishes.

	The toolspace also contains the gadget "consume©me" whichtells the system to add some media to its internal mega©database.

	Everything I've said here has been Amiga Specific forclarity of example.  There is no reason why this tool could notbe made available on the Macintosh, IBM, Atari, NeXT.

A little bit about the author:

	Anselm Hook is a rather nomadic free-lance programmer whohas been quite busily occupied since 1978 writing "just abouteverything from Oil Patch Software to Arcade Games" to proposalsvery much like this one, thank you very much.


Yours Truly
Anselm Hook

of Software Alchemy