Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!rutgers!att!cbnewsm!nsw
From: nsw@cbnewsm.ATT.COM (Neil Weinstock)
Newsgroups: comp.sys.amiga
Subject: Re: Clipboard support, and why it hasn't happened.
Summary: Here goes nothing
Message-ID: <4998@cbnewsm.ATT.COM>
Date: 4 Oct 89 17:32:25 GMT
References: <4272@sugar.hackercorp.com>
Reply-To: nsw@cbnewsm.ATT.COM (Neil Weinstock)
Organization: The Flying Squid Patrol
Lines: 26

In article <4272@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes:
[ ... ]
Re: clipboard:
>	* It must be no harder to use the clipboard than it is to use
>	  a file. The easiest way to do this is to provide a CLIPBOARD:
>	  handler. That way you could open CLIPBOARD:0, write stuff,
>	  and close it with no more difficulty than you have now creating
>	  a file in RAM:.

I'll bite.  How is this any different from using RAM in the first place?
What if you were to define a standard subdirectory, RAM:clipboard (maybe do
	assign clipboard: RAM:clipboard
by default), and a standard name for the default "current" clipboard entry, and 
leave it at that?  This would involve little or no work in the OS, and only 
minimal work on the part of the applications, since all they'd have to do is 
consider all clipboard-like operations to be file operations hard-wired to 
a particular file in RAM:.

In the abstract sense, how is a clipboard any different from a file in a 
dynamically resizable RAM disk?

    ________________    __________________    ____________________________
////                \\//                  \\//                            \\\\
\\\\ Neil Weinstock //\\ att!cord!nsw  or //\\ "Oh dear, now I shall have ////
//// AT&T Bell Labs \\// nsw@cord.att.com \\//  to create more Martians." \\\\
\\\\________________//\\__________________//\\____________________________////