thywiss@csvax.cs.ukans.edu (John A. Thywissen) (05/13/89)
#define PHILOSOPICAL_MODE 1
The discussion of file requester libraries, has brought up the notion of
modular functionality of a system. This is a problem that can be
generalized beyond simply file requesters and the like. Computer
scientists have been "chewing" on this type of problem for years. One
solution, already mentioned on the net is the concept used in
Smalltalk--Abstract Data Types.
An abstract data type is a module defined in terms of an object, i.e. a
file requester, with operations on it, such as create a new requester,
display it, etc. User programs of the object are NOT allowed to operate
on the object directly, only to ask the Abstract Data Type (ADT) to
perform operations in the user's behalf. Amiga libraries are an
implementation of ADTs.
Now, not only can ADTs be useful for items such as scroll arrows, file
requesters, and the like, but also for larger objects like "a formatted
text file" (as produced by a word proccessor), a IFF ILBM picture (as
produced by your favorite paint program). In the course of some
applications, such as a mail system, there may be call for an object
produced by another system. So, your mail system should be able to say,
in a standard way, "Edit this text file and put the results here", just
as Rob Peck proposed a way for an application to say "Ask the user to
pick file and tell me what it is".
If there would be some standardized way to call these other modules then
there would no longer be dilemmas such as which text editor for messages
to stick in that wonderful mail system you are devloping. (I like
MEmacs, but Joe (not his real name :-) ) would sooner be boiled in oil
then use any Emacs derivative.) The application would just
EdBase = OpenLibrary("STD_EDITOR:editor.library",0);
/* Path & name stuff needs
standardization, too */
stdReturnCode = EditFile("T:draft_message");
CloseLibrary(EdBase);
I propose the somehow, there should be a standardization effort for
callable interfaces to applications and that a registry, similar to
CATS's IFF registry, be set up. Essentially, the interface
specification would amount to a ".fd" file and a corresponding AutoDoc.
Users then could just "drop in" whichever application/module they like
and run.
Another proposal (wow, two for the price of one!): Perhaps even the
application could ask for "give me an IFF ANBM form", and the 'system'
could look up which programs were capable of producing that type of
object, and then ask the user which one to use. (Another file
requester!!)
-------
John A. Thywissen <thywiss@csvax.cs.ukans.edu>
1122 West Campus Rd. Rm. 213 /| |\/| | / \ |\
Lawrence, KS 66045-8081 / | | | | | | \
(913) 864 2646 _/_-_-_|_ _|_ _ _|_ _|_ _ _\__|_ _|_-_-_\doug@xdos.UUCP (Doug Merritt) (05/13/89)
In article <15323@louie.udel.EDU> thywiss@csvax.cs.ukans.edu (John A. Thywissen) writes: > >I propose the somehow, there should be a standardization effort for >callable interfaces to applications and that a registry, similar to >CATS's IFF registry, be set up. Essentially, the interface >specification would amount to a ".fd" file and a corresponding AutoDoc. Interestingly enough, the freeware Andrew Toolkit (under X windows, usually on Unix) supports this notion. I'm still trying to figure out the release tape (currently my only source of info), but they definitely support dynamically-loaded applications into an already-running process, so that (I think) multimedia documents can specify execution of some module that is not previously known to the system, and it can do so very efficiently. Wish I knew more about it. Looks like they may have done quite a number of things "right". Doug -- Doug Merritt {pyramid,apple}!xdos!doug doug@xdos.com Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary "Of course, I'm no rocket scientist" -- Randell Jesup, Capt. Boinger Corps
mp1u+@andrew.cmu.edu (Michael Portuesi) (05/15/89)
> Excerpts from ext.nn.comp.sys.amiga: 13-May-89 Re: Callable Application > In.. Doug Merritt@xdos.UUCP (1108) > In article <15323@louie.udel.EDU> thywiss@csvax.cs.ukans.edu (John A. > Thywissen) writes: > > > >I propose the somehow, there should be a standardization effort for > >callable interfaces to applications and that a registry, similar to > >CATS's IFF registry, be set up. Essentially, the interface > >specification would amount to a ".fd" file and a corresponding AutoDoc. > Interestingly enough, the freeware Andrew Toolkit (under X windows, > usually on Unix) supports this notion. I'm still trying to figure > out the release tape (currently my only source of info), but they > definitely support dynamically-loaded applications into an > already-running > process, so that (I think) multimedia documents can specify execution > of some module that is not previously known to the system, and it > can do so very efficiently. Yes, everything you've said is correct. The mail system here at CMU uses the Andrew Toolkit, and it is possible for people to mail each other working dynamic objects. For example, I could mail another person a clock that actually tells the time of day, or a calculator that actually adds numbers when you click on it. The system is based around objects that are written in an object-oriented dialect of C. The runtime mechanism provides a dynamic loading capability that loads code for and initializes instances of objects on demand. Objects can be imbedded inside one another -- examples include the calculator and clock imbedded in a mail message, or bit-mapped pictures as part of a piece of text. Adding new objects to the system is a matter of creating a new dynamic object and placing it somewhere on your dynamic object search path. > Wish I knew more about it. Looks like they may have done quite a number > of things "right". What else would you like to know? --M -- Michael Portuesi * Information Technology Center * Carnegie Mellon University INTERNET: mp1u+@andrew.cmu.edu * BITNET: mp1u+@andrew UUCP: ...harvard!andrew.cmu.edu!mp1u+ MAIL: Carnegie Mellon University, P.O. Box 259, Pittsburgh, PA 15213