Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!quintus!pds
From: pds@quintus.UUCP (Peter Schachte)
Newsgroups: comp.sys.amiga
Subject: Re: How 'Bout HyperCard!
Summary: IFF doesn't go quite far enough
Message-ID: <987@sandino.quintus.UUCP>
Date: 16 May 88 22:20:45 GMT
References: <15372@uflorida.cis.ufl.EDU> <31411@linus.UUCP> <3768@cbmvax.UUCP>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 29

In article <3768@cbmvax.UUCP>, andy@cbmvax.UUCP (Andy Finkel) writes:
> In article <956@sandino.quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes:
> >Ok, my big reservation about clipboards:  they really NEED to be
> >object-oriented.  When I select (or copy/cut) a spreadsheet, or
> >animation, or picture, or chunk of a wysiwyg document, it needs
> >to carry along with it information about how to manipulate it, or AT
> >LEAST how to display it.  The only general way to do this that I know
> >of is with code.  The code needs to be encapsulated with the data.
> 
> The way we do it is via IFF...all data sent to/from the clipboard.device
> must be IFF, which *is* self-identifying.

IFF data is self-identifying, but that really isn't enough.  In order
to use this approach, every program must include all the code for
dealing with all the kinds of data that they expect someone to try to
paste in.  As the diversity of the Amiga environment increases, this
will be more and more impractical.

In comp.sys.amiga.tech, I recently suggested a solution to this problem
which basically amounts to having a library for each kind of thing
(object) that multiple applications may want to deal with.  The library
contains all the procedures for doing things with these objects, such as
displaying them on a screen.  The library also contains the info about
how to read and write the object to a file, which would answer some
people's complaints about the pain of parsing IFF files.
-- 
-Peter Schachte
pds@quintus.uucp
...!sun!quintus!pds