eachus@mitre-bedford.ARPA (Robert Eachus) (03/31/88)
Let me make a proposal for one part of the elephant. We need to
be able to have software find out about your preferred and current
environment transparently. For example, many disks come equipped with
read-me files which invoke THE AUTHOR's preferred display program if
you click on the icon. What I want to happen is for such a file to
invoke the program specified by ENV:Display as the default or to pass
the file to whatever program currently running handles display of text
files. And of course we need to do this in a way that allows Fred
Fish disks, etc. to do something rational on systems without a ENV:
assignment.
When you think about how to do this in an upwardly compatible
manner, the entire mechanism becomes clear. First we need tools which
reference ENV: (if it exists) and invoke the systems preferred tool if
no other tool which accept that type of message is running, or hands
the application over to a running tool which knows about that class of
applications, or handles the application itself. A little messy, but
in general the code to do all this needs only be written once and put
in arp.library or ipc.library or some_other.library, we choose. If
the library call does not return or signal an error, the application
vanishes. Otherwise it does its usual thing.
A tool which is willing to handle additional applications while
it is running calls a different entry in the library to say here I am,
and here are the protocols I talk, and the classes of things I can
handle. A simple example, Emacs would accept TEXT, MAIL, and READ
(read only) tasks. But MAIL and READ would probably go elsewhere if
Emacs was not currently executing in some task. I assume the library
would put up a requestor if there were two or more handlers for a
given class of objects. Communication protocols (IPC's) might be
different for different classes of task (not AmigaDOS tasks but here I
mean types of jobs to be done), or they could be identical (as for
READ and TEXT above).
Now as I see the scope of this (IPC) project first we need to
establish the library (server) protocol and the format of things in
ENV: (or whatever you want to call it). The formats in ENV: should be
user readable and editable. Next we need to establish the original
classes of tasks (applications), and the appropriate information in
.info files. Finally the protocol for talking to the library needs to
be standarized. Once all of these are in hand, all we have to do is
write the initial version of the library.
I hope that the number of formats and communication channel types
is small, but notice that this library doesn't need to know anything
about the application specific protocols, just the messages to
establish the communication path. Additional protocols can use their
own libraries, or be built into this one. Also I would hope that the
ENV: device would be a directory (copied into RAM: by your start-up I
hope) in which the server library would put icons for all servers that
it knew about, and would thereby provide a user with a way to edit
the characteristics of the active servers (i.e. to tell the server
library that a read-only file should cause more to be invoked instead
of passing the file to emacs).
One last issue, we may need to have more than one classe for some
objects. A C program should have class C as well as class TEXT. If
the tool invoked (by clicking on the icon, from the CLI there is no
ambiguity) is clever it will ask whether to compile or edit the file
before calling the server.library to find out which tool to invoke to
do the editing (or compiling).
Robert I. Eachus
with STANDARD_DISCLAIMER;
use STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return FLAMES is...joe@dayton.UUCP (Joseph P. Larson) (04/05/88)
I'd like to also point out that sometimes software might come with a program that you really, truly do want to use to read a particular piece of text. Thus, if you are going to do something like this, you should allow for an "ignore_env" bit... Also -- you aren't going to come up with all the classes people might use. Face it -- you aren't. People who really start using it are going to set up the pictures with DPaint, their music with DMCS. C programs get one editor while maybe Pascal programs get the same editor but maybe they want to call it differently. Finally, I'm not sure how it currently all works, but it would be nice if one could specify a fancy command line to call the program with. This way you could call up my_editor with one command file containing macros if it's a c program and a different command file if it's a letter to your mother.... Whatever. -J In article <28104@linus.UUCP> eachus@mbunix (Eachus) writes: > > Let me make a proposal for one part of the elephant. We need to >be able to have software find out about your preferred and current >environment transparently. For example, many disks come equipped with >read-me files which invoke THE AUTHOR's preferred display program if >you click on the icon. What I want to happen is for such a file to >invoke the program specified by ENV:Display as the default or to pass >the file to whatever program currently running handles display of text >files. And of course we need to do this in a way that allows Fred >Fish disks, etc. to do something rational on systems without a ENV: >assignment. > > One last issue, we may need to have more than one classe for some >objects. A C program should have class C as well as class TEXT. If >the tool invoked (by clicking on the icon, from the CLI there is no >ambiguity) is clever it will ask whether to compile or edit the file >before calling the server.library to find out which tool to invoke to >do the editing (or compiling). -- UUCP: rutgers!dayton!joe Dayton Hudson Department Store Company ATT : (612) 375-3537 Joe Larson/MIS 1060 (standard disclaimer...) 700 on the Mall Mpls, Mn. 55402