sharp@fsd.cpsc.ucalgary.ca (Maurice Sharp) (01/25/91)
The 7.0 toolbox provides all that is necessary to create pipe
applications. A pipe is just a filter, you bung data in one end, it
does some transformations on that data, and bugs it out the other. Of
course, the in and out can also be pipes.
Under 7.0, you can create a background only application. That is,
one that has no (or little) interface, and runs entirely in the
background. You drop a data file on the application, and it can do its
stuff. It could produce another data file at the end, or it could
invoke another faceless application with the output. Sounds like a
pipe to me.
So which software company is working on pipes ? And how about a
graphical interface to put together an arbitrary sequence of pipe
applications ? I hear the chime of the cash register already.
maurice
--
Maurice Sharp MSc. Student (403) 220 7690
University of Calgary Computer Science Department
2500 University Drive N.W. sharp@cpsc.UCalgary.CA
Calgary, Alberta, T2N 1N4 GEnie M.SHARP5francis@uchicago.edu (Francis Stracke) (01/28/91)
In article <1991Jan25.092823.16868@cpsc.ucalgary.ca> sharp@fsd.cpsc.ucalgary.ca (Maurice Sharp) writes: The 7.0 toolbox provides all that is necessary to create pipe applications. A pipe is just a filter, you bung data in one end, it [...] Under 7.0, you can create a background only application. That is, one that has no (or little) interface, and runs entirely in the background. You drop a data file on the application, and it can do its stuff. It could produce another data file at the end, or it could invoke another faceless application with the output. Sounds like a pipe to me. It sounds like what Mess-Dos calls a pipe, sure. But you don't get any communication until the app is finished. Under Unix, data is sent to a special buffer, and the receiving app can read it any time. You can, with a bit of work, set up 2 pipes, and get 2-way communication, which is clearly not possible with this scheme. That being said, it remains true that AppleEvents and other IAC may work reasonably well as pipes. Anybody know how much data you can send with one call this way? (If nothing else, you could use same-node AppleTalk, which would work even pre-Sys7.) -- /=============================================================================\ | Francis Stracke | My opinions are my own. I don't steal them.| | Department of Mathematics |=============================================| | University of Chicago | Until you stalk and overrun, | | francis@zaphod.uchicago.edu | you can't devour anyone. -- Hobbes | \=============================================================================/
roy@phri.nyu.edu (Roy Smith) (01/29/91)
francis@uchicago.edu (Francis Stracke) writes: > It sounds like what Mess-Dos calls a pipe, sure. But you don't get any > communication until the app is finished. Under Unix, data is sent to a > special buffer, and the receiving app can read it any time. Historical note: there was once a version of Unix that was designed to run on, I believe, LSI-11's with limited memory (which, at the time, probably meant less than 64k). To make it fit, the kernel was stripped of everything that could possibly be taken out, including the pipe code. The shell still supported pipes, however; you could do "foo | bar" which the shell just turned into "foo > temp; bar < temp" for you. No, I never used this version, I just remember reading about it in an old issue of BSTJ. My guess is that it never made it out of The Labs. -- Roy Smith, Public Health Research Institute 455 First Avenue, New York, NY 10016 roy@alanine.phri.nyu.edu -OR- {att,cmcl2,rutgers,hombre}!phri!roy "Arcane? Did you say arcane? It wouldn't be Unix if it wasn't arcane!"
rmf@cs.columbia.edu (Robert M. Fuhrer) (01/29/91)
I think an important point is being glossed over here. In Unix, pipes can be set up by users at the shell level because processes inherit their I/O connections/descriptors from the parent process. Thus, with the "standard input" and "standard output" channels being a well-known convention, a user can construct a pipeline of (almost) arbitrary programs *at the command shell level*. This doesn't require rewriting each program in the pipe to explicitly support pipes (as opposed to any other type of I/O source/sink). Of course, the Unix programs/tools for which it makes sense to place in a pipeline are typically simpler tools than those found in the Mac world. For instance, they typically are short on user interface. Off the top of my head, pseudo-visionary, and probably full of holes: At the same time, if I/O streams could somehow be "standardized," perhaps using a mechanism similar to the TYPE/CREATOR tags given to files, I could still envision redirecting the input/output streams of even applications with a GUI. To make this truly useful & general would probably entail defining a format for an action stream (a sort of command language, but I hesitate to imply a strong connection to something like MPW or CSH's command language) that would serve as directions for an application. So we'd have a "control stream" for telling the application what to do to its input(s) (e.g., print, perform a search/replace), an input stream which would serve as the "open document" for the application, and an output stream, to which the results of the control streams actions (the state of the document at the end?) would be pushed. The success of this clearly depends on the success of encapsulating a control stream's format. One simple (and probably insufficient) approach is to use a dummied-up event stream, perhaps from a "demonstrative" run of each program in the pipe (i.e., to demonstrate what is to be done). Naturally, for this to be any better than running each program in turn on temp files, you'd have to be able to capture the control stream for that program so as to use it in later invocations, or perhaps refer to it elsewhere in the pipe as appropriate. Well, anyway, enough said about nothing in particular. Comments everyone? -- -------------------------- Robert M. Fuhrer Computer Science Department Columbia University 1117B Fairchild Building Internet: rmf@cs.columbia.edu UUCP: ...!rutgers!cs.columbia.edu!rmf
aland@chaos.cs.brandeis.edu (Alan D Danziger) (01/29/91)
In article <RMF.91Jan28163427@chopin.cs.columbia.edu> 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,minow@bolt.enet.dec.com (Martin Minow) (01/30/91)
In article <FRANCIS.91Jan28105635@daisy.uchicago.edu>, francis@uchicago.edu (Francis Stracke) writes... > >That being said, it remains true that AppleEvents and other IAC may >work reasonably well as pipes. Anybody know how much data you can >send with one call this way? (If nothing else, you could use same-node >AppleTalk, which would work even pre-Sys7.) > I didn't notice any limit on the buffer sizes, but would recommend reasonably small buffers to keep network latency reasonable (otherwise, you ruin the for other people). If you have long messages, you can send them in multiple network packets. A few other minor points: -- PPC Toolbox (and, I suppose, AppleEvents) work even if AppleTalk is disabled; which is nice if you have a stand-alone system with an ImageWriter. -- PPC Toolbox sends the data buffer along with 3 32-bit words of additional information (userData, blockCreator, and blockType) along with a "partial message" bit, so many interactive applications don't even need a data buffer. -- It doesn't appear to be trivial to write a package that supports PPC Toolbox on System 7, but defaults to AppleTalk (ATP, probably) on earlier systems. It's obviously possible, but it might be a fair amount of work with little payback. In general, I think that PPC Toolbox (and AppleEvents) offer a number of advantages over Unix pipes, and might prove to be the most significant new feature of System 7. Martin Minow minow@bolt.enet.dec.com
francis@uchicago.edu (Francis Stracke) (01/31/91)
In article <19566@shlump.nac.dec.com> minow@bolt.enet.dec.com (Martin Minow) writes: -- It doesn't appear to be trivial to write a package that supports PPC Toolbox on System 7, but defaults to AppleTalk (ATP, probably) on earlier systems. It's obviously possible, but it might be a fair amount of work with little payback. In general, I think that PPC Toolbox (and AppleEvents) offer a number of advantages over Unix pipes, and might prove to be the most significant new feature of System 7. What about ADSP? Is there an equivalent of that in the PPC Toolbox? If you just supported that on both Sys7 and on earlier systems with AppleTalk, you'd have a very nice form of pipe: creatable between any 2 processes, on different nodes, etc. If there were a bunch of such plug-and-play piping programs, you could (possibly) establish a hypercomputer on your net. Or you could just have a truly wonderful extension of Unix's strictly linear in-shell pipes. (Def.: A hypercomputer is a system of sharing out unused resources of machines on a net to simulate an extra computer. The factorization that was done by Email last year was an example of a hypercomputer job.) -- /=============================================================================\ | Francis Stracke | My opinions are my own. I don't steal them.| | Department of Mathematics |=============================================| | University of Chicago | Until you stalk and overrun, | | francis@zaphod.uchicago.edu | you can't devour anyone. -- Hobbes | \=============================================================================/