Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!decwrl!pa.dec.com!bacchus!mwm From: mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) Newsgroups: comp.sys.amiga.programmer Subject: Re: Need ideas on an ARexx port for a large, powerful database manager Message-ID: Date: 26 Apr 91 20:10:31 GMT References: <1991Apr25.031733.9576@netcom.COM> Sender: news@pa.dec.com (News) Organization: Missionaria Phonibalonica Lines: 60 In-Reply-To: rodent@netcom.COM's message of 25 Apr 91 03:17:33 GMT In article <1991Apr25.031733.9576@netcom.COM> rodent@netcom.COM (Ben Discoe) writes: There are two tricky issues: how should the application send information back to the ARexx command sender, and what about when dBMAN is already busy running some command? The second question is easy - but depends on what your application already does. If you only allow one window/project at a time, then return an "I'm busy". You might consider allowing a macro to queue a command for later. You should definitely provide a "lock" facility, so that a macro can guarantee that it has access to the database (i.e. - the user and all other macros are locked out). Macros started by the user from inside of dbMAN should probably start locked, and certain commands should probably be illegal unless the macro has a lock. If you provide multiple projects/windows, then each Rexx port should have a "windowless project", and be as independent as any other window (sorry, I'm not familiar with dbMAN). The public port should only allow queries about the state of the server, and the ability to get a new Rexx port with full capabilities. The first question isn't that much harder. The rule is simple: if you're returning a single string, use RESULT. If you're returning structured data, use the RVI. MFF+ does a good job of allowing access to data base entries (thought it's not a full-blown database); you might take a look at how it does this (hmm - it also does the locking/unlocking I talked about above, so...). This is a bit uncomfortable, since it introduces a function REXXREPLY that must not be used by anyone except a calling ARexx macro. What method have other developers used in their ARexx interfaces? Having functions that are only available from Rexx is SOP once you've added a Rexx interface. For example, you almost certainly don't provide commands for opening/closing windows, reshaping them, or whatever. But if someone wants to integrate dbMAN into a presentation, they'll need that. More importantly, locking/unlocking or getting a new Rexx port are things a macro will want to do that it doesn't make sense for the user to do. The simplest task is adding a "REXXSEND()" function to send Arexx commands out from dBMAN programs. No problem with doing it this way, right? That's fine. It's not strictly required, as a user can use a string macro to do "address thing do text-from-dbMAN". However, this requires that they have ARexx to send Rexx messages, which may or may not be acceptable to you. If you're really interested, I've gave a BADGE talk on doing exactly what you're in the middle of. I can email you the text of that talk.