m0154@tnc.UUCP (GUY GARNETT) (04/11/91)
[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 ...]
Wildstarm0154@tnc.UUCP (GUY GARNETT) (04/11/91)
[if you don't want to to read this long thing, hit "n" now!]
A Conversion Utility for the Amiga (Part 2 of ?)
(A modest proposal from "Wildstar"; 200 lines)
- this document is freely distributable -
4) Details
Application Interface: A client application communicates with the
conversion facility via standard Exec messages (but see the
discussion of IPC, below). In order to make conversion requests, the
application will need a message port with a unique name. Each
request is a separate message, and is sent to the convertor client
message port "ConvClientPort". The convertor will copy the request
into its queue, and reply the message (which can then be freed or
re-used as needed). When the requested function has completed, the
convertor will verify that the client's message port still exists,
and if so, it will send a results message. The client should reply
this message as soon as it is done with it. If the client message
port does not exist, the convertor will assume that the client has
exited, and will discard the results.
Possible Requests: A client can request several functions of the
convertor. The client could request a data conversion (convert this
data from a format to another format; for example, from IFFILBM to
EPSF), recognition (for example, is this valid IFFILBM data?),
identification (what is this data?), cancellation (cancel all pending
requests), convertor status (list clients, requests queued, in
progress, and completed, and other information), module status (list
modules, source and target formats, and lock status), lock a module
(ensure that a given module is loaded and stays loaded), and unlock a
module (remove a module lock). The last four request types can be
used to implement a monitor for the conversion utility, or by
applications to manage the convertor.
5) More Details
Module Functions: Modules need to implement a number of control
functions in order to operate properly within the conversion
facility. All modules must implement a status function (which
returns information about the current status ofthe module), a cancel
function (which cancels the current operation, if any), and an exit
function (which requests that the module exit, if possible).
Each module can optionally implement functions for some or all of
the following data operations: convert (sorce data format to target
data format; it is assumed that this is the primary function of most
modules), recognise (a data format; determines whether or not the
data is in a specfied format), and identify (determines the format of
data whose format is unknown). It is not necessary to implement all
(or even implement any) of the operations for a module to function
properly (but a module which implements no operations is unlikely to
be used). The convertor will request only one operation at a time
from each module (multiple requests will be queued internally by the
convertor) to simplify module logic.
Module Installation: Modules are program (tool) files, stored in a
logical device CONVMOD:. Any legal file name is a legal module name,
although it is suggested that it be mnemonic for the function of the
module (like "PS-to-IFF"). It is also suggested that they be
provided with icon (.info file) for two reasons: Ease of
installation by the end user (just drag this icon into your
"Conversions" drawer) and to provide the convertor with additional
information.
Tool Types: If an icon is present for a given module, the tool
types can be used to provide the convertor with information about the
capabilities of the module. The following tool types could be used:
VERSION (to specify the version of this module for the user's
reference; for example, VERSION=1.10), SOURCE (to specify the source
formats that this module can translate, multiple formats can be
separated by a vertical bar character; for example,
SOURCE=IFFILBM|IMAGE|BITMAP), TARGET (to specify the target formats
produced by this module; for example, TARGET=POSTSCRIPT|EPSF), and
FUNCTION string (to specify the data operation functions supported by
the module; for example, FUNCTION=CONVERT|RECOGNISE). Other tool
types should be ignored by the convertor.
Module Initialization: When a module is executed, it should
initialize itself, and create a message port for receiving requests.
This port should have a unique name (multiple copies of a given
module can be loaded, and if so, a mechanism should be provided to
generate unique names). When it is ready to begin receiving function
requests, it should send a message to the convertor module, via its
module message port "ConvModulePort". The message should contain the
module's name (the name of a message port to which the convertor can
send module requests), and version, source, target, and function
information (as above). If the information provided by scanning the
tool types differs from the module's startup message, the convertor
should assume that the tool types are incorrect for this module. This
may result in the convertor sending an immediate termination request
to the module, and continuing its module search. The convertor will
copy information from this startup message, and will reply it as soon
as possible, so that it can be freed or reused.
Request Interface: The convertor will request operations by the
module with exec messages. Each message will request a module
function, and should be replied as soon as the convertor has copied
the pertinent information. The convertor ensures that no more
request messages will be sent until the current one is replied. When
the operation is complete, the convertor should send another message
to "ConvModulePort" with the results. If "ConvModulePort" should
dissappear (it shouldn't) the module would be perfectly justified in
assuming that everyone else left and didn't tell it (discard the
results and terminate the module). The convertor will maintain an
internal queue of pending requests for a given module (and may load
multiple copies of a given module, if the situation warrants).
However, each module should periodically check its message port while
processing a request. The convertor may request that the module
terminate, cancel the current request, or provide status information.
6) Still More Details
Convertor: The convertor itself should be started before any
modules are executed (if it is not, and a client program "manually"
starts some modules, the convertor may not be aware of those modules,
and may load additional copies, wasting memory). The convertor
maintains two message ports, "ConvClientPort" (for receiving requests
by client modules) and "ConvModulePort" (for receiving startup
messages and result messages from modules).
Internals: The convertor should maintain a list of all currently
loaded modules, their capabilities, and their current status. It
should also maintain queues of requests destined for those modules, a
list of currently-known clients, and a list of pending requests
(pending a startup message from a module, that is). The convertor is
responsible for starting and terminating modules (so that it can
implement the module lock and unlock features). The convertor may
optionally use this information to manage its memory usage by
terminating currently unused modules (and to retain unused modules
which are likely to be needed again). The convertor may also cache
information (gleaned from tool types, or from prior executions of the
module) about modules which are not currently loaded, if provision is
made for invalidating or updating this data (for example, when the
user installs a new module in the middle ofa session).
Requests: Requests from clients are queued at the convertor's
client message port, and are processed in the order that they are
received from that port. Therefore, it may be possible to use the
message priority can be used to implement a "rush" processing scheme.
(most clients should use a priority of 0, so that requests are
processed in first-in, first-out order). As each request is
received, it becomes the current request, the client information is
added or updated in the client list, and the convertor searches for a
module to perform the request.
Loading Modules: When a module is loaded, the current request
(which, by definition, caused that module to be loaded), the search
status for that request, and related status information is placed on
a pending list. The module will (hopefully) load and execute,
sending a startup message to the convertor's module message port. As
startup messages are received, the module is added to the convertor's
module status lists, and the pending list is searched for the request
(or requests) which caused the module to be loaded. If the convertor
determines that startup messages have been received from all modules
which have been requested, any pending requests are released to
continue with the search process.
Searching: When searching for a module to fufil a client request,
the convertor should use a four-phase search. The search is
complete when a module which can fufil the current request (as
determined by that modules startup message) has been loaded.
First, the convertor examines its list of currently-loaded modules.
If one of them can fufil the current request, it is queued for
processing by that module. If another request is on the pending list
(waiting for a module to load), the current request is also placed on
the pending list. If neither of these conditions is true, the search
continues with the next step.
Second, it should examine the tool types of all modules which have
icons. Any modules whose tool types indicate that they can fufil the
current request are loaded. If the module's startup message does not
confirm that it can fufil the request, the search continues (with
this step, or if all icons have been searched, with the next step).
Third, modules without icons are loaded, one by one (with the
request being placed on the pending list each time). If no modules
can be found to satisfy the request, the search proceeds the next
step.
Fourth, modules with icons, but that were not loaded in the second
setp, are loaded (with the current request being placed on the
pending list each time). If no modules can be found to satisfy the
request, the search fails (no module is available to convert the
requested data). This step is also optional, it can be selected by a
conversion facility option (perhaps by a switch on the convertor at
startup time). If the fourth step is not enabled, then the search
ends after the third step.
To avoid heavy disk and memory demands, as well as excessive
conversion time, it is recommended that all modules have an
assoicated icon file.
Module Management: It is quite possible for modules to be loaded
for wich there is no current need (either as a result of the search
process, or because it has no more requests to process). Each time
the convertor loads a module, it should also check the list of
currently loaded modules. If there are any which have never had a
request, it should terminate them (it is likely that they are the
result of a failed search). The convertor should also consider
unloading modules which have been used in the past, but are currently
idle.
[to be continued ...]
Wildstarm0154@tnc.UUCP (GUY GARNETT) (04/11/91)
[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".
Wildstarpeterk@cbmger.UUCP (Peter Kittel GERMANY) (04/11/91)
In article <790@tnc.UUCP> m0154@tnc.UUCP (GUY GARNETT) writes: > >(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. You sure should look a little deeper into the IFF definition! Then you would learn that there are sure possibilities inside IFF to provide the features you desire, see for CATs and LISTs, for example. Though I very much appreciate this effort to get a powerful conversion machinery, I strongly wish that this hopefully will NOT lead into inventing dozens of new "standards"! This should NOT be encouraged, as I got a little of an impression in part 2. I bet that nearly all of these desired formats can easily be satisfied with IFF or at least in a way to expand the IFF definition in the proper IFF manner. We should take all efforts to keep IFF *THE* interchange format. It has already paid in the past, and should even more in future. It already spreads to the PC world and I heard rumors that Microsoft jumps on this waggon, too (though they are said to call it different?). If you stick to IFF, we could even consider to involve good-ole Clipboard in this project. Clipboard is until now sort of a sleeping beauty, but perhaps its concept could be used with advantage here. Aside from this, I wish good luck for this project. -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
m0154@tnc.UUCP (GUY GARNETT) (04/15/91)
In article <1098@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >In article <790@tnc.UUCP> m0154@tnc.UUCP (GUY GARNETT) writes: >> >> 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. > >You sure should look a little deeper into the IFF definition! Then >you would learn that there are sure possibilities inside IFF to provide >the features you desire, see for CATs and LISTs, for example. > >Though I very much appreciate this effort to get a powerful conversion >machinery, I strongly wish that this hopefully will NOT lead into >inventing dozens of new "standards"! This should NOT be encouraged, >as I got a little of an impression in part 2. I bet that nearly all >of these desired formats can easily be satisfied with IFF or at least >in a way to expand the IFF definition in the proper IFF manner. > >Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... >Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk I know about the IFF standard; it is a very flexable and capable framework for implementing just about any type of data format. I am not trying to introduce any new "standards"; I'm simply trying to make best use of the ones we already have. If programs like ProWrite, AegisDraw, ProDraw, MaxiPlan, Scribble, Microfliche Filer, Superbase, etc ... would save all of their data in IFF files, the conversion facility would not be needed. Instead, each of these applications (and many others) define their own data storage formats. And usually, these formats are not well explained (if at all) for other programs to yse. What I am trying to do do is provide a way go get each of these "proprietary" formats (I am calling them external formats in the formal document) into something which is a recognised, useful Amiga "standard" format for that kind of data (this includes IFF formats, of course, and probably some non-iff standards as well ...). What the conversion facility is trying to provide is a common ground where (with only a little extra effort on the part of the applications programmer) these proprietary data formats can be converted to the appropriate Amiga standards. With the conversion facility, a paint program could (for example) import any graphic file (including ProDraw, CAD drawings, and other formats) by requesting that the conversion facility turn it into IFF ILBM). Similarly, a DTP program could print just about anything to a PostScript printer by requesting that the conversion faciliy translate it to PostScript (from whatever, let's say CAD drawings, IFF pictures, ProDraw pictures, etc ..). It could print the same thing to a Preferences-supported dot-matrix printer by requesting conversions to an internal bitmap. IFF will be very important to the conversion facility; however, I feel that other "standard" formats will be required, too. Wildstar
perry@madnix.UUCP (Perry Kivolowitz) (04/16/91)
In article <791@tnc.UUCP> m0154@tnc.UUCP (GUY GARNETT) writes: > A Conversion Utility for the Amiga (Part 2 of ?) > (A modest proposal from "Wildstar"; 200 lines) This is all very nice. But it has already been done. Why do it again? -- Perry Kivolowitz, ASDG Inc. ``We look for things. Things that make us go.'' UUCP: {harvard|rutgers|ucbvax}!uwvax!astroatc!nicmad!madnix!perry CIS: 76004,1765 PLINK: pk-asdg
kent@swrinde.nde.swri.edu (Kent D. Polk) (04/18/91)
In article <1813@madnix.UUCP> perry@madnix.UUCP (Perry Kivolowitz) writes: >In article <791@tnc.UUCP> m0154@tnc.UUCP (GUY GARNETT) writes: >> A Conversion Utility for the Amiga (Part 2 of ?) >> (A modest proposal from "Wildstar"; 200 lines) > >This is all very nice. But it has already been done. Why do it >again? Where does it exist? What exists that allows me to programmatically pass a pointer, etc. to a bitmap in a message & get an encapsulated Postscript file as a result? Or a set of DR2D commands & get it rendered, or get the Postscript output of an IFF bitmap file? And have the server automatically loaded and purged when no longer needed? I need an extensible client/server mechanism like this & I sure haven't seen it anywhere. Remember the recent "Renderer" thread? I see it and this "A Conversion Utility for the Amiga" to be the same thing, as they address the same problems. If you talking about "The Art Department", I agree that TAD is an excellent program, but I sure don't see it performing the types of rendering/conversion functions that is being discussed here. I brought up this concept about 2 years ago specifically with regard to rendering 'devices'. My mailbox was flooded with messages explaining to me that there is absolutely no need for this type of thing on the Amiga so I shut up and listened. I still disagree, and I still need these types of operations since they still don't exist. In the meantime, I developed a pseudo-generic event oriented data acquisition system which, for once in my 14-year professional career, allowed me to write an extensible set of programs to perform acquisition and filter operations ONCE (Ok, maybe twice :^). No more writing massively duplicated programs for every blasted test I had to run! It's like going shopping now. "Let's see, I need a Tek 2430 sampler here, two of those plot windows here and there, a gating function there, a real fft over here, a Hamming window here, a envelope function there, a time shift based on the gate threshold over yon. Also want to save the results after that fft and when it's all done. There, off we go. Hmmm, that's interesting, I wonder what channel 1 would sound like with a different set of gates than the fft was done on? Ok, another gate function at the end here and that Play routine. Very Interesting!!" Each of the filter operations is (usually) a tiny little program which only has to handle the specific function for which it was designed. It was also designed around PPIPC (Fish disks) which made the messaging and server loading mechanism almost trivial and extremely fast. ------------------------------------ Now, I want to extend this mechanism to allow for a whole list of things which I need to accomplish. Renders, converters, etc. accessed from within my small, self-contained processes. I need "Real" Modular Programming, not just modular at link time... What would it look like? A configuration where you would list your available servers. This could be a server to do about anything you wanted on the Amiga. A program needs a service performed on its data? A simple message... a server gets loaded if not already... Results. (BTW, PIPC provides the mechanism for this stuff already - just have to write the servers and the final config routine). I guess what I am saying is that I want a different way of computing and am trying to do something about it. I also think it would be nice and quite convenient if others decided to do the same, but I have found that I think a bit unconventionally, so it is usually only after I have finished needing something that others discover its' significance :^( BTW Perry, This wasn't personally directed to you. I just don't want to see this concept thrown away. I also don't think it will necessarily compete with TAD. I don't work with pictures & don't need a picture conversion utility, but I do need data rendering & output capabilities. Why don't we all go take another look at PPIPC and open minds a little? Thanks, ===================================================================== Kent Polk - Southwest Research Institute - kent@swrinde.nde.swri.edu "What will happen to our memory now that we can keep it on paper?" =====================================================================
hill@evax.arl.utexas.edu (Adam Hill) (04/19/91)
In article <1813@madnix.UUCP> perry@madnix.UUCP (Perry Kivolowitz) writes: >In article <791@tnc.UUCP> m0154@tnc.UUCP (GUY GARNETT) writes: >> A Conversion Utility for the Amiga (Part 2 of ?) >> (A modest proposal from "Wildstar"; 200 lines) > >This is all very nice. But it has already been done. Why do it >again? But Perry, the current implementations of this type of program is neither PD nor are there specs for TADPRO modules. I see this type of program to be very useful for the average person that can pay the bucks for a commercial program. I see this as a very programmable "engine: for automatic file conversion. I could write a front end in let's say CanDo! that would display IFF pics. Now the program could redily display ANY picture type if there exists a conversion module to port to IFF. Or as a simple PD version of xxxPRO. We might not have 4Cast RIP modules or even TARGA ones, but we could do IFF types, Postscript and FTXT. There will prolly be some "special" cases. For POSTSCRIPT we could use Adrian Aaylwards POST.library and for DCTV we could use the DCTV.library that was just put up on BIX. And perhaps at a later date we could adapt it to support "Active regions" in the new graphically oriented version of EMACS that is being worked on. PD software seems to me to be the most satisfying form of artistic expression ...... >Perry Kivolowitz, ASDG Inc. ``We look for things. Things that make us go.'' -- adam hill -- hill@evax.uta.edu ASOCC - University of Texas at UTA I programmed for three days Make Up Your Own Mind.. AMIGA! And heard no human voices. Amiga... Multimedia NOW! But the hard disk sang. - TZoP Born To Run SVR4