Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!mit-eddie!bbn.com!nic!chaos.cs.brandeis.edu!chaos!aland From: aland@chaos.cs.brandeis.edu (Alan D Danziger) Newsgroups: comp.sys.mac.misc Subject: Re: 7.0 CAN pipe (was Re: System 7.0 vs. NeXT Step) Message-ID: Date: 29 Jan 91 02:18:25 GMT References: <11468@helios.TAMU.EDU> <1991Jan23.204448.23778@unx2.ucc.okstate.edu> <5646@idunno.Princeton.EDU> <2898@casbah.acns.nwu.edu> <1991Jan25.092823.16868@cpsc.ucalgary.ca> <1991 rmf@cs.columbia.edu (Robert M. Fuhrer) writes: RMF> In Unix, pipes can be set up by users at the shell level because RMF> processes inherit their I/O connections/descriptors from the RMF> parent process. Thus, with the "standard input" and "standard RMF> output" channels being a well-known convention, a user can RMF> construct a pipeline of (almost) arbitrary programs *at the RMF> command shell level*. This doesn't require rewriting each program RMF> in the pipe to explicitly support pipes (as opposed to any other RMF> type of I/O source/sink). Off the top of my head, RMF> pseudo-visionary, and probably full of holes: RMF> RMF> At the same time, if I/O streams could somehow be "standardized," RMF> perhaps using a mechanism similar to the TYPE/CREATOR tags given RMF> to files, I could still envision redirecting the input/output RMF> streams of even applications with a GUI. To make this truly useful RMF> & general would probably entail defining a format for an action RMF> stream (a sort of command language, but I hesitate to imply a RMF> strong connection to something like MPW or CSH's command language) RMF> that would serve as directions for an application. (Not to be picky, but...) Does this description sound to anyone else just a little similar to HyperTalk and AppleEvents? This type of process is just what the combination is for... InterApplication Communication at its strongest! Basically, the way I understand it, what Apple had in mind was for one program to be able to modify 'packets' sent from another. These packets would be similar to the buffers which Unix pipes & I/O streams use, and can be treated accordingly within the IAC metaphor. BTW, the clipboard could be used for this as well, or a separate 'IAC Buffer' could be created at need. The one issue I would ask Apple to consider, if this is implemented, would be that they have this 'IAC buffer' deleted once used. Having a 300k Clipboard File around when I don't need it, or even a 0k clipboard file, gets slightly annoying for some reason... -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alan D. Danziger, | 753 South St,Waltham MA 02154 | "What a drag, aland@chaos.cs.brandeis.edu | MB 3130 / Brandeis University | it is, (617) 894-6859 or 647-3720 | PO Box 9110 Waltham MA 02254 | getting old" =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alan D. Danziger, | 753 South St,Waltham MA 02154 | "What a drag, aland@chaos.cs.brandeis.edu | MB 3130 / Brandeis University | it is,