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