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


[if you don't want to to read this long thing, hit "n" now!]
 
           A Conversion Utility for the Amiga (Part 3 of 3)
            (A modest proposal from "Wildstar"; 141 lines)
              - this document is freely distributable -
 
7) Additional Items
 
  IPC:  From what I have read on the net, IPC seems well suited to
this scheme; however, I do not know enough about it to tell for
sure.  In any case, a library of functions for constructing, routing,
and parsing messages will be needed.  If someone (perhaps the author)
who knows a lot about IPC can comment on this, I would appreciate it.
 
  ARexx:  It should be possible to define the message formats so that
it is compatible with ARexx's RexxMsg system.  This would have the
advantages that ARexx macros could act as conversion clients, and
would allow the use of some (relatively) well-known message passing
and argument parsing routines.  The disadvantage is that the scheme
would require users to own either AmigaOS v2, or ARexx itself.  I
would prefer that the conversion facility operate reliably under
either operating system.  Comments anyone?
 
  Dynamic Linking:  The standard Exec message passing facilities seem
to be adequate to the task.  I feel that dynamic linking would not
add sufficient functionality to be worth the trouble.
 
  Amiga "Quickdraw":  Rather than define a new rendering standard, I
would prefer that the conversion facility be generic and extensible. 
I feel that a new rendering standard would not add sufficient
functionality to be worth the trouble at this time.  However, in the
future it may be necessary or desirable to define new standard
formats to improve the utility of the conversions facility.
 
  Hot Links:  I have not specifically addressed "Hot Links" in
conjunction with the conversion facility.  While this would be a very
good feature to add to it, I am not completely sure how difficult it
would be.  However, it is a topic well worth discussion, and could
concievable be added to the conversion facility at some later time (I
can already imagine one way that it could be done, see below).
  To me, the term "Hot Link" implies that two (or more) applications
are co-operatively sharing data.  For example, a client DTP package
might have, embedded in the current document, a drawing created by a
paint package (the originator of that data).  If "hot links" were
used, the originator could be invoked to edit the drawing. 
Periodically (like when the user saved his changes) the originator
would notify the client (or clients) of the changes, and they would
update accordingly (without the user having to take any additional
action).
  I can imagine adding code to a convertor module to manage such hot
links, through an additional message port (perhaps named for the
format being linked).  For this reason, the ability was added for an
application to request that certain modules be loaded without
performing any conversions.
 
  Distribution and Ownership:  The specifications for the conversion
facility should be placed in the public domain.  In this way,
programmers could write modules, and even new versions of the
convertor (and supporting library) with confidence.  At least one
version of the convertor should be made freely distributable (or
included by Commodore on an operating system distribution) so that it
is available to all Amiga users.  Modules will probably be written as
(or as part of) commercial products, in addition to any that are made
freely-distributable.
  It seems to me (and I admit, I could be naive here) that by making
modules which support some proprietary format available to all, the
value of the application which produces files in that format will be
increased.  Because more people would be able to use those files in
other projects, they would be more likely to purchase the
application.  Conversely, any application which included conversion
modules with its distribution would be more valuable too, because
purchasers would know that it could then exchange data with their
other applications.
 
  Standard Formats:  A small set of standard formats will help reduce
the number and complexity of modules; but a large number of standard
formats will increase the utility of the conversion facility.  To
this end, a relatively small number of standard formats should be
selected, with an eye toward general utility.  The set should
probably include at least one format from each of the following
categories: Amiga Internal Representations, External Bitmaps, Text,
2D Structured Drawings, and 3D Structured Drawings.  Other categories
like Animation, Sound, and Composite Formats (formats which contain
members from more than one of the other categories) should be
considered.  My current thoughts on the standard formats include:
  Amiga Internal: Intuition Image, and rendering through a RastPort
(probably supplied by the client).  Size, Scaling, and Palette should
be able to be specified by the client, or allowed to default. Modules
should support as many of the Amiga display modes as possible.
  External Bitmaps:  IFF ILBM (including HAM, EHB, and possibly some
form of IFF 24-bit).  Rendering to these formats is probably not a
lot of additional trouble, after writing a module which can handle
the Amiga internal formats.  What about adding a module interface to
some of the existing bitmap conversion programs?
  Text: "Vanilla" ASCII text, and some form of enhanced text (will
the IFF FTXT formt work for this, or should we use one of the many
"standards" available for borrowing, like DCA/RFT?).
  2D Structured: There is a relatively new IFF DR2D standard for
structured graphics on the Amiga.  I suggest we support it. 
Additional suggestions include PostScript (encapsulated or not?),
HPGL (HP Graphics Language; used in HP Plotters), and HP PCL (HP
Printer Control Language; used in HP laser printers).
  3D Structured: As far as I know, there is no standard here.  How
about suggestions, or should we try an convince Syndesis to release a
version of their 3D conversion utility with a module interface?
 
 
8) Toward a Specification
 
The following items need additional work, clarification, or
discussion before a formal specification can be generated.
  ** The list of standard formats needs to be agreed upon, and all of
the relevant specifications should be collected (and, if necessary,
referenced or included in the convertor specification).
  ** Further work on the message format must be done, most
importantly, to decide between a "convertor-specific" format, the IPC
format, or the ARexx format (see the IPC and ARexx items above).
  ** The exact set of functions and results used by each section of
the conversion facility need to be specified.  I have noted the kind
of information which needs to be passed, but have not specified the
interfaces.
 
I expect (and hope) to generate a lot of response with this post, and
would like to offer the following guidelines:  If your response will
serve as an item for further discussion, post it to the newsgroup, so
that everyone who is interested can comment on it.  Comments which
you want considered for the specification can be emailed to me, if
you would perfer to save bandwidth.  Flames can be sent to /dev/null
or to NIL: (as the case may be), or if you must mail them to me
rather than posting them on the net.
 
9) Disclaimers
 
My boss doesn't know I'm doing this.  Any trademarks mentioned here
belong to their owners (suprise!) and no infringement was intended.
Any resemblance to an actual document, living or dead, is purely the
result of a fever (blame it on the flu virus).  SillyWords is a new
product of WackyWares, "Your VaporWare Headquarters", the publisher
of the highly acclaimed "RSN Project Manager".
 
Wildstar