Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!sun-barr!apple!well!shf
From: shf@well.UUCP (Stuart H. Ferguson)
Newsgroups: comp.sys.amiga
Subject: Re: Clipboard support, and why it hasn't happened.
Message-ID: <14083@well.UUCP>
Date: 13 Oct 89 06:18:00 GMT
References: <4272@sugar.hackercorp.com> <4998@cbnewsm.ATT.COM>
Reply-To: shf@well.UUCP (Stuart H. Ferguson)
Organization: The Blue Planet
Lines: 56

+-- nsw@cbnewsm.ATT.COM (Neil Weinstock) writes:
| 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,
| 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?  
| In the abstract sense, how is a clipboard any different from a file in a 
| dynamically resizable RAM disk?

There are several differences.  1.  The clipboard device deals differently
with multiple simultanious access than a ramdisk.  A write to the clipboard
will always be sucessful, whereas an attempt to write to RAM:clipboard/0
might fail if the file was being accessed by another application.  This
is generally not a problem since the clipboard is used mostly interactively
anyway, but it's something to think about. 

2.  (and this is more important) The clipboard device has a defered post
mechanism, so that a provider of the clip need not actually write the clip
to the clipboard unless there is a consumer out there who wants it.  This
is done with messages.  For example, suppose some application with pictures
in some internal format uses "cut" and "paste" commands to move the
picture around internally.  It may be innefficient to convert to ILBM format
from the internal format every time the user specifies a "cut," so the
application uses it's own internal fast cut and paste buffer.  But what
if the user wants to "paste" to another application?  The application can,
every time the user "cuts" an image, inform the clipboard that is has
something to post.  If the paste is internal, it can use the fast paste
buffer.  If the paste is into another application, the other application
will try to read the clipboard.  The clipboard says, "Hey wait!  I don't
have the data yet!," blocks the read attempt and sends a message to
the source application to satisfy the post.  The source application engages
its engines to convert the internal format to ILBM, and writes that to
the clipboard.  When it has the data, the clipboard now completes the 
operation started earlier and gives the data to the destination application.

Notice that with the above scenario, anyone reading the clipboard would
see it as if the data were already there, when in fact the data wasn't
there until after it was asked for.

Do that with a file.

3.  By being a distinct device, the clipboard defines an interface that
can be extended.  The satisfy/post mechanism is only one such enhancement.
To dumb tools it can look like a file and they won't be any the wiser.  
To clever programs, it can have much more elaborate behavior and be more
like a clearinghouse for data transfer, or IPC with a device-like
interface.
-- 
		Stuart Ferguson		(shf@well.UUCP)
		Action by HAVOC		(ferguson@metaphor.com)