Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!stanford.edu!agate!violet.berkeley.edu!pete From: pete@violet.berkeley.edu (Pete Goodeve) Newsgroups: comp.sys.amiga.programmer Subject: Re: Hyper Functionality [was Re: Amiga Conversion...] Message-ID: <1991Apr29.071720.17169@agate.berkeley.edu> Date: 29 Apr 91 07:17:20 GMT References: <1991Apr26.073554.10580@agate.berkeley.edu> Sender: root@agate.berkeley.edu (Charlie Root) Organization: University of California, Berkeley Lines: 66 In (26 Apr), Mike Meyer (mwm@pa.dec.com) writes: |> [That's a dangerous tack, Mike... I mean, why should we abandon MS/DOS |> for MultiTasking, anyhow...(:-)(:-)] > >Because it allows us to do things that we can't do with MS/DOS. There are actually very few goals one ABSOLUTELY can't reach in some fashion using MS/DOS -- it's just one hell of a pain getting there. My point was that I saw that argument in print many times, and this one sounds suspiciously similar. > > ARexx isn't strong in those things. But I'm not suggesting using > ARexx; I'm suggestiong using the the Rexx Message protocol. But if you don't connect to the interpreter, there's VERY little point in using the message format. It provides no standard to hang ANYTHING on. The point I am trying to pound home is that ppIPC is DESIGNED to do jobs that ARexx is not (and vice versa of course). Even though you CAN drive a screw with a hammer, choose the best tool for each job. > > As for your objections to ARexx - part of them amount to "I don't like > doing it that way." For some reason, I can't see that as valid. Well (sigh) I guess I'd better go back to using Fortran then. I don't like that language either, but obviously that's not a valid reason for using C. I tried to put my REASONS for not liking ARexx for these purposes in full view. You don't agree. Fine. I guess you prefer doing everything with ARexx. For some reason I can't see that as valid. I'm beginning to wonder if you've actually READ the ppIPC specs? If not, this whole discussion has been kind of pointless. And so we go round the merry-go-round again. Time to get off, I think. One more time (again) I'll state briefly the reasons for preferring ppIPC: 1) It is designed to be fairly BULLETPROOF -- against processes going away, and against mismatching of messages. 2) The message format is SELF-IDENTIFYING. This is becoming more and more a standard way of handling data. IFF is the prime example (and actually the first I can remember encountering) but then there is HDF, which seems to be coming into wide use, and a number of other formats used where a lot of independently written programs have to know exactly what data they are reading. 3) It provides MANAGEMENT protocols for things like indicating who should be responsible for a data buffer passed in a message -- should it be returned to the client, or retained by the server it is sent to? 4) There are ancillary optional facilities like a `Broker' for automatic location and loading of the process which will serve a new port that a client has opened. 5) The basic overhead (without the optional ancillaries) is as low as possible --two and a half K of resident library. Message passing is at full exec message rate -- no repetitive searching for the port each time you send a message (as ARexx has to do for safety). That's it. Somebody else's turn on this ride.... I have more important things to do. -- Pete --