Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!tnc!m0154
From: m0154@tnc.UUCP (GUY GARNETT)
Newsgroups: comp.sys.amiga.programmer
Subject: An Amiga Conversion Facility (1 of 3) LONG
Message-ID: <790@tnc.UUCP>
Date: 10 Apr 91 19:37:38 GMT
Reply-To: m0154@tnc.UUCP (GUY GARNETT)
Organization: The Next Challenge, Fairfax, Va.
Lines: 151


[First of all, I would like to apologise for two things: the length
of this post (if you don't want to read a lot about a file-format
conversion standard, hit "n" now), and the length of time it has
taken to prepare it.  The former is a direct consequence of the
complexity of the topic, and my own propensity for words.  The latter
is due to many things, including the flu ...]
 
           A Conversion Utility for the Amiga (Part 1 of ?)
            (A modest proposal from "Wildstar"; 150 lines)
              - this document is freely distributable -
 
(1) Background
 
  Reason:  Current Amiga data exchange is based on IFF files. 
Although this system works very well for bitmap data (thanks to IFF
ILBM), and performs adequately for animation (IFF ANIM), and sound
(IFF SMUS and IFF 8SVX), there are few other widely recognised data
interchange formats.  "Multimedia" and "Desktop Video" (the things
the Amiga does best) as well as more conventional "Productivity"
applications (like word processors, spreadsheets, and databases)
would benefit from the ability to exchange data in a wider variety of
formats.
 
  Method:  A "universal conversion utility" would allow an
applications program to convert any applicable data into a format
that it could utilize.  This conversion facility could use external
modules to convert data to any applicable standard formats.  By
carefully selecting a limited number of standard formats,
applications programs could get maximum use from "foreign" data.
 
  Design Criteria:  A practical conversion utility must meet several
neeeds.  It should be relatively easy for the user to install in his
or her computer system (about as easy as installing a harddrive or
Arexx, and preferably much easier).  It must be easy for an
applications programmer to incorporate in a new application, and
should not be too difficult to retrofit into an existing one (about
as easy as supporting ARexx would be about right).  It should be
extensible (so that new formats can be supported without requiring a
redesign or complete re-implementation of the entire system); a
modular system would be nice (so that new formats are supported by
attaching "modules" to an established conversion system).  Finally,
the entire thing should be designed using shared libraries to reduce
the total size of the conversion facility.
 
(2) Definitions
 
  Amiga Internal Format == Any data format which is defined by the
Amiga hardware or system software.  Examples include Intuition
Images, Screen bitmaps, audio data, and sprite data.
  External Bitmaps == Any external format (see below) which contains
bitmap data; for example, IFF ILBM, any of the various 24-bit file
formats, TIFF, MacPaint, and many other graphics storage formats fall
into this category.
  Client == An application program which uses the conversion facility
to perform some operation.  Operations are typically conversions, but
could also be format recognition, or anything else supported by the
conversion facility (for example, "Hot Links").
  Conversion Facility == The complete "system" of conversion modules,
the conversion host, and supporting message ports, files, etc.  We
are trying to create a specification for this conversion facility.
  Convertor == An executable program which acts as a mediator between
modules and clients.  The convertor runs as a process and is
typically started by the system startup-seqence.
  External Format == Any data format defined by any applications
program; there are, of course, thousands of external formats running
around in the world today.  For example, database files, structured
drawings, IFF files, and postscript programs are all examples of
external formats.
  Format Identifier == An arbitrary text string which is used to
identify external and standard formats.  Formats which are identified
by the same string are assumed to be the same format.  The creator or
owner of the format should try to pick a meaningful (and unlikely to
be accidentally duplicated) identifier.  For example, a good
identifier would be "SillyWords-Doc-V1", but "WPFile" would be bad.
  Module == An executable program which can be called upon to perform
data conversions from a specific set of source formats to a specific
set of target formats.  Each module runs as a process, and is
typically started by the convertor as needed.
  Originator == An application program which created the source data
in question.  Originators may also be clients.  The exact originator
of an external format is not important (except for "Hot Links") to
the conversion facility, as long as the format can be recognised.
  Source == Arbitrary data, to be converted to the target format.  It
is presumed that most conversions be from source data in an external
format to target data in a standard format, but source data can be
any any format recognised as valid by a conversion module.
  Standard Format == A data format defined as being "supported" by
the conversion facility as a target.  The definition of the
conversion facility should include references to (or should directly
include) the definitions of each of the standard formats.
  Target == Arbitrary data, converted from the source format.  It is
presumed that most conversions will be to target data in a standard
format from source data in an external format, but target data can be
in any format recognised as a valid target by a conversion module.
  Text Format == Any file which contains textual information.  It may
be in the form of "vanilla" ASCII, which contains the text characters
and virtually nothing else to any of a number of rich text formats
(which contain formatting information in addition to the tex
titelf).  An IFF text format exists, but has been largely unused.
  2D Structured Format == A structured drawing contains a coded
representation of each object (point, line, arc, etc) in the drawing.
Structured drawing programs (like ProDraw), drafting applications,
etc. all produce 2D Structured data.  There is an applicable IFF
standard, DR2D (it is presently supported by 
  3D Structured Format == A structured drawing of a three dimensional
object.  Although some CAD programs may produce 3D objects, most
Amiga 3D objects are created by object modelling packages (like Turbo
Silver, LightWave, and Caligari).  There is no IFF standard for 3D
structured objects.
 
3) Overall Design
 
  Theory:  Applications communicate with the convertor via standard
messages.  The convertor searches for, loads, and issues commands to,
modules necessary to satisfy the client request.  The convertor and
its modules also communicate via standard messages.  When the
conversion has ended, the convertor notifys the client, and the
transaction is ended.
 
  Startup:  At system startup, the convertor is executed; it should
check for other copies of itself (most easily done by searching for
its own message ports), and then initialize.  Initialization includes
creating two public message ports, "ConvClientPort", and
"ConvModulePort". It should also register with the system low memory
server (the ASDG Low-Memory Server comes to mind here) if one is
present.  The conversion facility is now ready to process conversion
requests.
 
  A Request:  Conversion requests are Exec messages (but see the IPC
item below) sent to "ConvClientPort".  Each message would contain
details about the conversion requested (a source block, a source
format block, a target block, a target format block, a parameter
block, and a result block) and the name of a message port to which
the results should be sent.  The convertor would search (using the
logical device CONVMOD:) for a conversion module capable of fufilling
the request.
 
  Results:  If at least one module can be found, it is asked to
perform the conversion (if more than one are found, the one with the
highest version number is used; if both have the same version number,
the modules are assumed to be identical, and one is selected
arbitrarily).  When the conversion is complete (or ended due to an
error), the convertor sends a message to the client.  The same
message format can be used.  The target block would contain the ouput
data (if any), and the result block would contain conversion result
information (to indicate "sucessful conversion", "unknown source
format", "unknown target format", "out of memory", etc.).
 
[to be continued ...]
Wildstar