Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!rutgers!bellcore!tness7!tness1!sugar!peter From: peter@sugar.UUCP (Peter da Silva) Newsgroups: comp.sys.amiga Subject: Re: Time is of the essence on IPC. Message-ID: <1831@sugar.UUCP> Date: 14 Apr 88 12:24:23 GMT References: <1705@van-bc.UUCP> Organization: Sugar Land UNIX - Houston, TX Lines: 85 Summary: Crosstalk In article ... lphillips@lpami.van-bc.UUCP (Larry Phillips) writes: > Well, I suppose pipes in a shell are a little different than the usual > approach, but I don't see any great problem with it. In fact, _something_ > should parse the pipe operator so that you don't have to muck about with > redirection kludges, and can just use a nice, short pipe operator like... > oh, let's use "|". Well, that's not what I was talking about. I'm not saying that the shell shouldn't do that... I'm just saying that the actual pipe handler should not be an magic part of another program. Rather, it should be something that DOS formally knows about. Of course in the current version of ConMan it is, but I didn't know that... not having a recent copy. But I feel better know that I know that I'm not the only one who's gotten confused on this subject :->. > As for an IPC protocol hooked to a programming > language, there are two things I would mention. > First, ARexx ports in a program do not necessarily need ARexx in order for > another program to use them. If an editor has an ARexx interface that > allows commands to be passed to it, any program can do a FindPort and send > commands. OK, but does any program other than ARexx actually do that? And I thought that a program's AREXX port was supposed to have a unique number tagged onto the end of it, so how's FindPort supposed to find it (of course I could be totally confused about *this*). Remember, whatever we come up with has to be usable by non-programmers. > It seems to me that the IPC protocol being spoken of on the net > will do exactly the same thing. It will also allow you to define a common pool of tagged message types that programs can use or ignore as they see fit, rather like IFF. > Second, allowing a programming language, especially a script/macro > interpreter to do the calling (and to accept commands, data, or status back > from a program) is a great way to make the facility even more powerful by > allowing the user, rather than only the programmer, to specify how any two > programs will interact Fine, but it should be up to the user to decide what that language should be. > Which programs of Bill's do you find frustrating? ConMan. > > You could send commands to REXX from programs that haven't been set up to > > deal with REXX. > The ARexx interface is well documented. All you need to do from any program > is a FindPort, then start sending messages that conform to the interface > spec. Of course with the type of IPC being discussed here recently, all > you would have to do is a FindPort, then start sending messages that > conform to the interface spec. And it shares the same problem. You're confused again... or is it just that you don't see why I would want to interface an existing program to this... like, say, DeluxePaint. > > One of the items on my stack of things to do when I have time is a CON: > > type handler that provides ANSI-style escape sequences to do things like: > > Menus. > > Function keys. > > Graphics (probably based on DEC Regis graphics). > > Changing the title bar. > > Adding a close box (that sends ^C). > > Scroll bars like the Bridge Card software's windows. > > And with a clipboard interface. That's the sort of thing that a CON: device > > needs. > Sounds a lot like the things you can do with WShell and ARexx. Really? In a standard console window running UNIX-type CLI-only programs that haven't been Amiga-ized? Or remotely via a terminal program like Matt Dillon's DTerm that opens a console window to do its rendering? Amazing. Plug here for Matt's program. It's very Zen. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter -- Disclaimer: These aren't mere opinions, these are *values*.