pete@violet.berkeley.edu (Pete Goodeve) (04/26/91)
In <MWM.91Apr23135328@raven.pa.dec.com> (23 Apr), Mike (My Watch Has Windows (mwm@pa.dec.com) writes: [... > What? You typed it in - and that's what it said. Well no, I DIDN'T type it in -- that was the point... I just took Dave's unposted text and put it out via my account. (:-)) Neverrr Mindddd.....] > > 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. Yes, I know you CAN handle arbitrary data with ARexx -- I just object to that paractice strenuously! Here you have a language that's supposed to be convenient for Joe User to learn to customize, and then you go and throw machine addresses and things at him... Furthermore there is no firm binding between a data-identifying tag, the data, and the operations that may be performed on it. OK, ARexx messages have a standard structure: 15 slots --- but that's IT! No standard for knowing the MEANING of data in those slots. > 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. ^^^^ Yup -- that's exactly my point... (:-)) > 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. Well, I thought (and still think) I had. When someone writes a MIDI package in ARexx that can chain multiple modules and run at adequate speed, prehaps I'll change my mind. In any event, Kent's eloquent description of his system surely settles the point. > 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. > [That's a dangerous tack, Mike... I mean, why should we abandon MS/DOS for MultiTasking, anyhow...(:-)(:-)] I'm not in the least advocating ABANDONING ARexx, though. It has opened up a lot of possibilities on the Amiga that didn't really exist before. To me, it's main strength is as a scripting language that's both totally flexible and adapted to multitasking -- something that only un*x otherwise has, and that not in nearly as user-accessible a form. It is NOT strong in either speed or handling complex data structures or flow networks, and this is where ppIPC fits. + + + + + I had a very frustrating and worrying -- though at the same time very entertaining -- experience tonight... [Hunh?? (:-))] I heard Bill Gates talk at BMUG (the Mac group, for those not aware). He spent a lot of time detailing his vision of the future (and Apple's -- with System 7.0) and, folks, it's awfully similar to what I and a few others have been hammering on for the last three years or so. He talked about modular smaller applications passing data between each other automatically on demand, self-identifying data objects that an application would know what to do with, and so on. The small difference being that on the Mac it is here NOW! (or at least when 7.0 arrives in May). (Their term is Interapplication Communication.) THEY have had to wait for a multitasking OS before they could think of such things [and of course System 7.0 comes on between 8 and 13 floppies...] but I'm very much afraid that the big boys may now leave C=A standing in the dust. WE've had multitasking since day 1, and we've just sat on our butts! (As an aside, I wonder if the present state of BADGE is another symptom of the state of affairs? Two years ago the room would be packed with argumentative idea-filled hackers. Now we're lucky if ten people show... (:-() My respect for Microsoft product may be pretty low, but my impression of Gates is that he still has dreams. Where are the dreamers (at least in a position to really do something about it) on our side of the fence? -- Pete --
mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (04/27/91)
In article <1991Apr26.073554.10580@agate.berkeley.edu> pete@violet.berkeley.edu (Pete Goodeve) writes: > 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. > [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. Now, if you asked why we should abandon OS/9 for AmigaDOS, that would be closer to what's going on... I'm not in the least advocating ABANDONING ARexx, though. It has opened up a lot of possibilities on the Amiga that didn't really exist before. To me, it's main strength is as a scripting language that's both totally flexible and adapted to multitasking -- something that only un*x otherwise has, and that not in nearly as user-accessible a form. It is NOT strong in either speed or handling complex data structures or flow networks, and this is where ppIPC fits. ARexx isn't strong in those things. But I'm not suggesting using ARexx; I'm suggestiong using the the Rexx Message protocol. It's not as complete as ppIPC, but is an established standard with lots of support, and comes complete with a nice language for playing with the messages. Kent's demo may indicate a serious application that can't be done with Rexx Messages; I need to sit down and look at it (when I find the time, which seems to be in short supply these days). 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. The other one is that you can't see asking people writing Rexx to deal with Hexx address, etc. I haven't suggested anything about having to do that, or even anything that requires you to do that. I've pointed out things you can do with Rexx messages that require that if you want to do those things in Rexx. While clumsy, it's a win that there's a language there _at all_. <mike -- Round about, round about, in a fair ring-a. Mike Meyer Thus we dance, thus we dance, and thus we sing-a. mwm@pa.dec.com Trip and go, to and fro, over this green-a. decwrl!mwm All about, in and out, over this green-a.
jonabbey@cs.utexas.edu (Jonathan David Abbey) (04/27/91)
In article <1991Apr26.073554.10580@agate.berkeley.edu> pete@violet.berkeley.edu(Pete Goodeve) writes: | |I had a very frustrating and worrying -- though at the same time very |entertaining -- experience tonight... [Hunh?? (:-))] [... the mac has structured, defined inter-app comm. NOW...] |THEY have had to wait for a multitasking OS before they could think of such |things [and of course System 7.0 comes on between 8 and 13 floppies...] but |I'm very much afraid that the big boys may now leave C=A standing in the |dust. WE've had multitasking since day 1, and we've just sat on our butts! | | |My respect for Microsoft product may be pretty low, but my impression of |Gates is that he still has dreams. Where are the dreamers (at least in a |position to really do something about it) on our side of the fence? | | -- Pete -- Commodore probably can't be aggressive in going after this because they don't have a large base of installed professional users who would take advantage of this enough to generate much new sales. The old bootstrapping problem. I think such a thing is definitely needed on the Amiga, though. I may have some amount of free time this summer.. I may be interested in working on this. Of course, I could do that a lot better if 2.0 were to come out for the 1000.. <bribe, bribe> 8-) The problem is really standardizing what we want, right? I really need to dive into the PPIPC docs. Maybe I can put them all in HT.. 8-) -- ------------------------------------------------------------------------------- Jonathan David Abbey \"Fortune presents gifts not according to the the university of texas at austin \ book" - Dead Can Dance "I've got to computer science/math?/psychology? \ jonabbey@cs.utexas.edu stay Awake..."
pete@violet.berkeley.edu (Pete Goodeve) (04/29/91)
In <MWM.91Apr26124744@raven.pa.dec.com> (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 --
mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (04/30/91)
In article <1991Apr29.071720.17169@agate.berkeley.edu> pete@violet.berkeley.edu (Pete Goodeve) writes:
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.
The point I'm trying to make is that the Rexx Message protocol may be
adequate for the job at hand, is an established standard, and has a
language available for playing with the messages.
ppIPC is certainly better for the job at hand. But is it enough better
to justify adopting yet another standard (thus adding to their major
feature - that there are so many to choose from), and giving up a
nice, interpretive language for prototyping things in?
Yes, choose the best tool for each job - but the "best tool" isn't
always the one that is technically the best; the rest of the world
needs to be considered.
<mike
--
He was your reason for living Mike Meyer
So you once said mwm@pa.dec.com
Now your reason for living decwrl!mwm
Has left you half deaddillon@overload.Berkeley.CA.US (Matthew Dillon) (05/01/91)
In article <MWM.91Apr29122929@raven.pa.dec.com> mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: >In article <1991Apr29.071720.17169@agate.berkeley.edu> pete@violet.berkeley.edu (Pete Goodeve) writes: > > 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. > >The point I'm trying to make is that the Rexx Message protocol may be >.. >ppIPC is certainly better for the job at hand. But is it enough better >to justify adopting yet another standard (thus adding to their major >feature - that there are so many to choose from), and giving up a >nice, interpretive language for prototyping things in? > >Yes, choose the best tool for each job - but the "best tool" isn't >always the one that is technically the best; the rest of the world >needs to be considered. On the otherhand, if you decide to stick to one thing forever you wind up in the same boat as all the poor IBM-PC users trying to run MSDOS compatible programs from Windows. Like AREXX, if ppIPC isn't *required* to use a program then gaining acceptance will simply be a function of its functionality. > <mike >-- >He was your reason for living Mike Meyer >So you once said mwm@pa.dec.com >Now your reason for living decwrl!mwm >Has left you half dead -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA