pete@violet.berkeley.edu (Pete Goodeve) (04/18/91)
[I'm posting this for Dave Navas, whose news server happens to be down... -- Pete -- ] In article kent@swrinde.nde.swri.edu (Kent D. Polk) writes: > >Where does it exist? What exists that allows me to programmatically >pass a pointer, etc. to a bitmap in a message & get an encapsulated >Postscript file as a result? Or a set of DR2D commands & get it >rendered, or get the Postscript output of an IFF bitmap file? And have >the server automatically loaded and purged when no longer needed? > >I need an extensible client/server mechanism like this & I sure haven't >seen it anywhere. Remember the recent "Renderer" thread? I see it and >this "A Conversion Utility for the Amiga" to be the same thing, as they >address the same problems. > >I brought up this concept about 2 years ago specifically with regard to >rendering 'devices'. My mailbox was flooded with messages explaining to >me that there is absolutely no need for this type of thing on the Amiga >so I shut up and listened. I still disagree, and I still need these >types of operations since they still don't exist. I absolutely positively don't want this thread to die. :) As far as I am concerned this is the extensibility that ARexx promised, but which is really beyond the means for it to deliver. Why so many Amiga programmers continue to spit out boring MS-DOS/Mac-type software is really beyond me. As far as I can see, this is really where the Amiga can shine far above it's competition. Can you imagine kludging Windows to do this? In real time? You've got a heartier imagination than mine, in that case... As far as I can see, this type of functionality is much like HyperLinks, except I've only seen HyperLinks described for data, not for functions. Correct me if I've misused, or appropriated the wrong terminology. So besides increasing the modularity of programs, what does this offer? How about a Word Processor where you can choose the features you want? A spreadsheet that can connect itself to a Simplex Algo. Solver and come up with business decisions based on available data? A database with Postgres-like functionality? A fully integrated on-line Help service? A modular DTP system that you can build into a CAD package, or a WP package, depending on your needs. Scientific Applications by the dozens. If there were 100hours to the day I'd be writing all of these. As it is, I haven't included my favorite, because I am writing it... This goes beyond data sharing -- dynamic or otherwise. More like a program requesting certain functionality, and a SupremeServer trying to meet those demands within the resources of the computer system at hand. Connect to a network, and everybody gets the *functionality* of each other's programs -- not just the ability to use each other's data/programs. Kind of like instant integration, were one to believe it were possible. I for one do... There are some technical difficulties for the general case. I will be working rather hard all summer to find and fix as many as possible, so STAY TUNED! >Why don't we all go take another look at PPIPC and open minds a little? What! And ruin my chance to come to market first! Horrors! :) > "What will happen to our memory now that we can keep it on paper?" >From experience :: it gets shredded. see reference :: Iran Contra Hearings.
pete@violet.berkeley.edu (Pete Goodeve) (04/18/91)
I notice that Dave didn't append any signature to the article I just posted for him, so just to make it quite clear... The initiator of the thread on "Hyper Functionality" is David Navas, not me! [... but of course I agree WHOLEHEARTEDLY with his comments (:-))] -- Pete --
mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (04/19/91)
In article <1991Apr18.065847.8050@agate.berkeley.edu> pete@violet.berkeley.edu (Pete Goodeve) writes: [I'm posting this for Dave Navas, whose news server happens to be down... -- Pete -- ] In article kent@swrinde.nde.swri.edu (Kent D. Polk) writes: > >Where does it exist? What exists that allows me to programmatically >pass a pointer, etc. to a bitmap in a message & get an encapsulated >Postscript file as a result? Or a set of DR2D commands & get it >rendered, or get the Postscript output of an IFF bitmap file? And have >the server automatically loaded and purged when no longer needed? > >I need an extensible client/server mechanism like this & I sure haven't >seen it anywhere. Remember the recent "Renderer" thread? I see it and >this "A Conversion Utility for the Amiga" to be the same thing, as they >address the same problems. I absolutely positively don't want this thread to die. :) As far as I am concerned this is the extensibility that ARexx promised, but which is really beyond the means for it to deliver. I disagree. I think ARexx can deliver this kind of functionality. There are two catches: 1) someone's got to write the clients; 2) someone needs to do the integration. Examples: I've added a spelling checker and a thesaurus to mg. Someone wrote the servers (ISpell + it's Rexx port, and the Electric Thesaurus), and I did the integration. I can see ADPro doing the bitmap/postscript mappings Kent talked about. I can even get the server automatically loaded & purged as it's needed - it's just that _somebody_ has to write the scripts that do this for your application. Whether you actually want that to happen is another question (I normally don't - I want the server running until I'm through with it). <mike -- It's been a hard day's night, Mike Meyer And I been working like a dog. mwm@pa.dec.com It's been a hard day's night, decwrl!mwm I should be sleeping like a log.
pete@violet.berkeley.edu (Pete Goodeve) (04/22/91)
In <MWM.91Apr18120110@raven.pa.dec.com> (18 Apr), Mike (My Watch Has Windows) Meyer (mwm@pa.dec.com) writes: > In article <1991Apr18.065847.8050@agate.berkeley.edu> pete@violet.berkeley.edu (Pete Goodeve) writes: You SEE? ^^^ vvvv ... I KNEW it would happen... (:-)) > [I'm posting this for Dave Navas, whose news server happens to be down... > -- Pete -- ] Those were DAVE's words -- not mine! Never mind, the response that follows is all my own work..: |> I absolutely positively don't want this thread to die. :) |> |> As far as I am concerned this is the extensibility that ARexx promised, but |> which is really beyond the means for it to deliver. > > I disagree. I think ARexx can deliver this kind of functionality. Oh, Mike,.. Mike... It seems we STILL aren't getting the message across. It's true of COURSE that ARExx is suitable for some Interprocess Communication jobs. Pipes *too* are fine for a lot of such things. Even an EXECUTE script running a sequence of programs that pass their data through intermediate RAM: files is perfectly good enough for a lot of requirements. Each has its area of applicability. But there *are* a lot of things that could be done that ARexx doesn't handle very well if at all. Just take another look at what you've actually used ARexx for: > Examples: I've added a spelling checker and a thesaurus to mg. Someone > wrote the servers (ISpell + it's Rexx port, and the Electric > Thesaurus), and I did the integration. These are all TEXT based things! That's what ARexx is great at. But what about all the other areas we've been talking about -- passing bitmaps and other data structures around, and passing them FAST? > > I can see ADPro doing the bitmap/postscript mappings Kent talked > about. [.....] But how does it pass them to other programs? ...On demand... Without both ends having to parse instruction strings...? Sure, it could write a file for another program to pick up, but I thought that was what the proposers were trying to avoid. Then there are all the other "Hyper Functional" opportunities. How would you pass MIDI events around at ARexx speeds? How would you use ARexx to build data acquisition, filtering, and processing "plug-in" modules that pass structured data around at high speed (as Kent has been doing with ppIPC)? (Actually MIDI is probabaly not a good example; it is specialized enough, and demanding enough, an application to deserve a system tailored to its own needs -- a function that Bill Barton's midi.library looks, at a very brief glance, to fill admirably. However, for communicating outside that domain -- say for a MIDI trigger to an image display animation -- you again want something more general, such as ppIPC.) It might clarify things a bit if I briefly describe how the IPCMessage format works in the context of the particular project I'm finishing up at the moment. One of the things this does is send (text) commands to other processes, which often receive them simply by opening an "IP:" device pipe. [Yes -- this is mostly a text based application here too, but other things are involved, as you'll see.] The normal ID of such a message is `CMND', which is one of the types that the IP-device recognizes. The only item in such a message is of type `LINE', which again the IP-device knows how to handle. When requested to do so, the program will output a more detailed message for recording purposes, indicating, as well as the command text itself, the channel (port) that the command is normally sent to. This is given the ID `DATA', and contains a `PORT' item before the `LINE'. If you want to receive this with an IP channel, you can do so (though normally it goes to a specialized program); the IP device recognizes the `DATA' ID, so reads the `LINE' properly, but simply ignores the `PORT'. (If you're doing it this way, this is presumably what you want...) You don't get ALL the information available in the message, but at least nothing breaks. In the other direction, the program has a single control port which can accept several kinds of messages, and passes them on to the appropriate handling routine with a brief switch/case sequence. (No command line parsing here!) One of the types is of course `DATA' -- of the same format as the ones it can send -- so that it can be restored to (selected parts of) a previous state. Another message type is `DUMP', which specifies a destination and causes it to spit out the `DATA' messages we were just talking about. Another message is `CNFG': this one configures the program in a number of ways, and is very flexible in format. Each possible configuration parameter has a corresponding item type (`WPOS' for window position is just one example) each of which may be present or absent as need dictates, and they may be in any order. Again, "parsing" is trivial -- just a loop that goes through the items in sequence, taking action via a switch statement. The parameters passed of course are already in the correct form -- mostly (short) integer for the configuration parameters. Any translation required from, say, keyboard input is done by the transient program that sends the message. You see the difference from ARexx, where the only way to distinguish message functions is by the command string itself, which needs parsing at the destination, and maybe other massaging as well. ppIPC message recipients can usually be very simple, and composing a message to send is not very complex either. Both are very fast. Command parsing only has to be done in one place -- often in a program that only runs long enough to do its job. Typically the server program doesn't need much text handling ability itself -- maybe not even text output, or at least only the most basic `puts' kind. The other side of the coin is that there is no particular user-level command language associated with ppIPC. Things are done via C-level (or any other compiled language for that matter) calls. There's no reason, though, not to use ARexx to manage the ppIPC connected processes, if that is appropriate and you can afford the speed penalty. Although ARexx can't generate IPCMessages, it can write or read an `IP:' channel just as well as any other program that can open a file. A net of ppIPC processes has to be commanded somewhere by the user -- most likely by a text string -- and ARexx can happily supply this. For ARexx control in other parts of the net, you could easily plug in the necessary links if you had to. Ah well -- another posting that's about twice as long as I'd hoped, but maybe it's made our rationale a little clearer. I'm not trying particularly to put down ARexx: there are a number of places in my usual environment where it's indispensable these days. However, there *are* multitasking applications that one can't do with ARexx, but can with something like ppIPC. All I want -- as Dave does -- is for people to expand their horizons from the linear old-style straightjacket. Think about it, folks. -- Pete --
mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (04/23/91)
In article <1991Apr22.071413.22219@agate.berkeley.edu> pete@violet.berkeley.edu (Pete Goodeve) writes: In <MWM.91Apr18120110@raven.pa.dec.com> (18 Apr), Mike (My Watch Has Windows) Meyer (mwm@pa.dec.com) writes: > In article <1991Apr18.065847.8050@agate.berkeley.edu> pete@violet.berkeley.edu (Pete Goodeve) writes: You SEE? ^^^ vvvv ... I KNEW it would happen... (:-)) What? You typed it in - and that's what it said. Those were DAVE's words -- not mine! Never mind, the response that follows is all my own work..: Yup - I knew that... I think I left the comment about who's words they were in it. > Examples: I've added a spelling checker and a thesaurus to mg. Someone > wrote the servers (ISpell + it's Rexx port, and the Electric > Thesaurus), and I did the integration. These are all TEXT based things! That's what ARexx is great at. But what about all the other areas we've been talking about -- passing bitmaps and other data structures around, and passing them FAST? Depends on how fast you want things. You can either pass contiguous chunks of memory around (Rexx strings don't have to be text), or ASCII strings that contain the pointer, or the raw pointer. I've done all of these with C structs in ARexx, and they all work fine. Now, you have to have a server that _expects_ those, but that's going to be a problem no matter what protocol you chose. In the other direction, the program has a single control port which can accept several kinds of messages, and passes them on to the appropriate handling routine with a brief switch/case sequence. (No command line parsing here!) Parsing command lines in Rexx is only required if you want to be nice to those who are using the server. If speed is more important than readability, you make your server provide function calls instead of a command line interface (better yet, do both), give the function calls one-character names, and switch on the first character of ARG0 (the function name). need dictates, and they may be in any order. Again, "parsing" is trivial -- just a loop that goes through the items in sequence, taking action via a switch statement. Yup - you get that with Rexx Function messages: it hands you a pointer to the function names, and pointers to the other arguments. You loop over the arguments doing what you will with the pointers, including the one-char switch hack above. You see the difference from ARexx, where the only way to distinguish message functions is by the command string itself, which needs parsing at the destination, and maybe other massaging as well. No, I see the difference between the way Rexx is conventionally used, and what you're doing. On the other hand, people don't conventionally provide servers that support function (as opposed to command) interfaces, and don't conventionally put anything but C strings into Rexx strings. That doesn't mean that those things can't be done. The other side of the coin is that there is no particular user-level command language associated with ppIPC. This is bad for ppIPC. This means there's not an easy way to test/prototype servers. That Rexx brings real IPC out to the scripting level is the only really interesting thing about the language. The underlying message passing facility is well-designed, and can do everything you want. Note that you _don't_ have to have ARexx to use clients and servers that pass RexxMsgs back and forth. ARexx just provides an interpreter that allows easy access to these things; the messages can be passed around without the interpreter. However, there *are* multitasking applications that one can't do with ARexx, but can with something like ppIPC. I don't think you've listed any such applications. At least, you haven't listed any that can't be done with the RexxMsg protocol. Like you, I'm not trying to put down ppIPC. I'm trying to find out why we should abandon a standard that - while not as flexible as ppIPC - appears capable of doing the job. <mike -- I'm gonna lasso you with my rubberband lazer, Mike Meyer Pull you closer to me, and look right to the moon. mwm@pa.dec.com Ride side by side when worlds collide, decwrl!mwm And slip into the Martian tide.
m0154@tnc.UUCP (GUY GARNETT) (04/25/91)
It seems to me that a ARexx => ppIPC program (or even function library) could be written fairly easily. It would have an Arexx port to receive commands (perhaps implement three basic commands: CreateIPC to create a new IPC message, AddIPC(tag,data) to add an item to the message, and SendIPC to send the thing once its built). The reverse should also be possible: a ppIPC => Arexx program. It would receive IPC messages, and reformat each item into an Arexx command, and fire it off to the current host. a "HOST" item could be defined, so that you could change hosts. With these two modules, anything that understands Arexx could be interfaced (with the appropriate Arexx script) to ppIPC. Wildstar