rodent@netcom.COM (Ben Discoe) (04/25/91)
Let your voice me heard, and influence the course of history! I am in the process of adding an ARexx port to dBMAN, a dBASE 3+ clone for the Amiga. How it will interface with ARexx should be influenced by what its users intend to do with it, so I'm posting here for suggestions. Many applications don't already have a command set, and must invent some to allow ARexx to send it meaningful commands. Well, dBMAN has hundreds of commands and functions (it is largely a database language), so I will assume if someone sends a string through ARexx, it should be treated as if they typed it directly at dBMAN's command prompt. This, receiving commands, is the easy part. 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? There's the "result" string that could be used, however, the caller would have to specially designate which expression would be passed back. This would look something like this, in an ARexx script: ADDRESS dbman options results 'select 48' 'use test index textndx' 'find joe' 'REXXREPLY(last_name)' name = result 'REXXREPLY(salary * 10.6)' raise = result 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? The simplest task is adding a "REXXSEND()" function to send Arexx commands out from dBMAN programs. No problem with doing it this way, right? Next, there the matter of what dBMAN should do when busy. dBMAN DOESN'T want to receive any commands when it's busy or executing a dBMAN program. Since waiting for ARexx messages occurs in the same code as waiting for key input, messages will naturally get queued up when dBMAN is busy, but there are times that it wants to respond to its live user only. (like when executing a compiled dbman program, when interpreting a command string could really confuse things.) In these cases, what is the appropriate thing to do with ARexx messages received? Simply send back an error meaning "sorry, I'm busy"? Thanks for your ideas, they will help the ARexx cause and make the Amiga even better. --------------- Ben Discoe, programmer, radical ecologist, old-timer Amigoid.
yorkw@stable.ecn.purdue.edu (Willis F York) (04/26/91)
rodent@netcom.COM (Ben Discoe) writes: > Let your voice me heard, and influence the course of history! >I am in the process of adding an ARexx port to dBMAN, a dBASE 3+ clone >for the Amiga. How it will interface with ARexx should be influenced >by what its users intend to do with it, so I'm posting here for suggestions. Yea!, I may have to go out and locate this program. (An arexx port would Sell me for sure) (Where and what's the $$ ~200$?) Stuff to watch OUT for. 1) Variable case port names, some programs name their rexx port stuff like This_Is_A_Rexx_Port, and that messes stuff up. Use all upper case, same for commands too. ] 2) Avoid 20+ character commands, MFF+ has some dosies like bring_selected_to_front (ICK!) (Underlines are nasty enough) 3) DOCUMENT IT WELL! With LOTS of examples! Look at other programs, look at CBM rules, and when in doubt make it logicial. Well hope to see it out soon. -- yorkw@ecn.purdue.edu aka Willis F York aka Squid on IRC The only thing that Apple invented is the idea to borrow Xerox-invented ideas. (Hope THIS sig don't insult anyone!) :^)
mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (04/27/91)
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.
<mike
--
How many times do you have to fall Mike Meyer
While people stand there gawking? mwm@pa.dec.com
How many times do you have to fall decwrl!mwm
Before you end up walking?