rokicki@neon.Stanford.EDU (Tomas G. Rokicki) (03/12/91)
> > One of the articles in NeXTWorld brought up the point that a multitasking > > environment like Unix favors small, specialized applications that the > > user can piece together exactly how he or she wants them. That seems > > like a pretty reasonable opinion. > > Does NeXT stress this at the Developer's Conference? > Yes. In a multitasking environment that also allows applications work in > harmony with each other, users like to have many applications running at the > same time. We encourage developers to remember that theirs will not be the > only application running. We've also seen many developers write great > applications that do a few things well and leave other jobs to other But wouldn't it be nice if somehow those apps could talk to one another? Under Unix, the paradigm is stdin/stdout and unidirectional streams of characters---and it's been quite successful. But with the NeXT, we can have message ports and messages with recursive requests! All that lacks is the arbitrary standard. Speaker/Listener is a good idea, almost halfway there. The problem with it is that if the user wishes to make application A communicate with application B, both applications need to have compiled-in knowledge of the other! This is unacceptable; I'm not going to recompile EMACS every time I add another app to my machine. And even if I were willing to, I don't have source to most of the apps on the machine! Public methods is another good idea, almost halfway there. But this time, we've severely constrained the things one app can do to another; most apps will have one or two public methods. What if I want to do something that the developer didn't think of? Take a clue from the Amiga community. Almost every application on the machine has an `ARexx' port---this is a message port that the application responds to in its event loop. The messages that can be sent to this port typically exercise almost every possible primitive operation the app supports---load, save, edit, change, display, exit, typeset, kill region, play (as in sound), etc. It's usually trivial to add such a port, since the commands mirror the user interface (and almost always uses the same code.) But now what can I do? Oh, the possibilities. I can use CPR (a debugging tool, like dbx or gdb) to debug my program, while editing it with emacs---and have CPR tell emacs where errors occured or where function definitions are or whatnot. So I don't need to fight with another editor. Then, when I recompile, the compiler (through an ARexx macro) points me at the compilation errors, where they occur, one by one, and I can easily fix them. Oh, you don't like EMACS? Fine, use the vi clone---it will work in the same way. You are using Manx C instead of SAS/C? Again, modify a few macros and you have the same environment. That's for expert users. What about the secretaries, writing up memos on the Amiga? The laser printer is on the mainframe; we don't want to teach the secretary how to typeset on the Amiga, upload the file to the mainframe, and queue it for printing. So we write a short ARexx script that adds a menu item to the secretary's editor. This menu item is called `print', and it runs the current document through the typesetter (TeX, Script, whatever), logs on to the mainframe, uploads the resulting file (using Kermit with the VLT terminal editor), and queues the printing. The secretary hit one key, and about five applications were brought into play in an interactive dance. This all works, and is powerful, and is a wonder to behold. Some day we may even be able to do it on the NeXT. -tom