Club Amiga de Montreal - CAM/CAM_CD_1.iso/files/339.lha/SerMod/Docs/ROBBS.intro.doc.pp/ROBBS.intro.doc

Text File | 1990-02-08 | 12.5 KB | 233 lines

Introduction to ROBBS

(c) Copyright Larry Phillips 1988

    The Amiga, by its very nature, encourages a different sort of
program. On some machines, you will see word processors integrated
with database managers, spreadsheets, and mailing list programs. Great
efforts are taken by the authors of these programs to provide a lot of
features, and to smoothly integrate the various parts of the package.
You will also, on single-tasking computers, find features in large and
small programs that do mundane small jobs, like deleting a file,
listing a directory, and so on.  The reason these features are there
is because it is usually not possible to do the job unless you are
willing to exit from a program.  If you've ever looked for a
particular program, or set of programs to do something like remote
updating of a database over the modem, you have probably come away
frustrated that the only programs you could find were those that could
only do it in a 'batch mode', after the day's business, and while your
local database program was inactive.  Well, we Amiga owners know that
there is a better way, and we have the machine that can solve this
type of problem.

    Because the Amiga is a multi-tasking machine, there is not much
reason for an author to include those features that are best handled
by other programs. As an example, your terminal program does not need
to be able to get a directory listing, because it is just as easy to
flip to a CLI (or bring up another CLI) to do the job. In effect, your
simplest terminal program is far more powerful, or at least
potentially far more powerful than any you might find on some other
machines.  You can run virtually all other programs while online,
giving you a freedom and flexibility that can only be dreamed of on
lesser machine.

    While this ability is important, there is another level of
versatility that is, as yet, untapped. It is nice to be able to run
different programs at the same time, but wouldn't it be much nicer if
you could use any program with any other program as if they had been
written to work together?  It isn't possible today, at least not with
all possible programs, given the programs we do have available, but it
could be at some future time.  I have heard an Amiga owner say "A
database, word processor, and animator linked together...  could put
Hypercard to shame." Personally, I can't think of a single use for
those three program types acting in an integrated manner, but the fact
is that someone did think it would be a marvellous thing.  I doubt the
author of any database program would even consider writing the code to
allow it to link up with the other two, and the same goes for the
other two authors.  Even if they did think it was a good idea, what
programs would they choose to link up with?  If it happened to be one
you particularly like, you'd be happy, but if not, you would probably
keep wishing that he'd chosen your favourite.

    These thoughts led me to the idea that what we really needed was a
series of building blocks designed to be hooked together, each
providing a limited, but necessary set of functions. I can't take
credit for the basic idea though.  This is a philosophy which has
stood the test of time in at least a few operating systems.  Unix is
one, and even if you have no particular love for Unix, you must admit
that the ability to build complex programs from simple, small programs
is a powerful idea. I wanted to go one step further though, and write
a series of modules that can be controlled to a finer degree. While
Unix allows manipulation of programs via stdin, stdout, pipes,
redirection, and intermediate files, I wanted to 'get into the guts'
of small programs and allow them to be manipulated more directly.

    The Amiga has a built-in feature that is ideal for our purposes. It
can send messages between programs via a system of message ports. A
message port is a simple idea. A program can create a message port,
give it a name, and register it with the operating system. Once that
is done, any other program can look for the message port by name, and
if the name is found, can then send a message to the port. The message
is received by the message port, and the program that created the port
can act upon that message in any way. The receiving program, of
course, must be able to understand the message. The receiving program
then replies to the message, to let the sending program know that it
was received, allowing the sending program to re-use the memory
allocated for the message.

    Prior to the advent of ARexx, the messaging ability of the Amiga
was limited to programs compiled in a number of different languages,
putting the capability beyond many Amiga owners. ARexx, however, has
full messaging ability, and can send messages to other ARexx programs
(scripts) or to programs written to understand ARexx messages.  This
opens up a whole new area for those would-be programmers who like
interpreted languages, allowing them to write simple (or not so
simple) ARexx programs to call other programs as 'building blocks', a
sort of a computer 'erector set' for applications.

    After months of talking to people about this idea, and not being
able to interest anyone in it to a sufficient degree thet they would
actually write modules, I decided to write a few myself. I have called
the series of modules ROBBS, for Rexx Object Building Block System.
The first module in the series is called SerMod (for Serial Module).
It was designed to be small (about 12K, but it could be made smaller
still), and to have a limited set of functions, dealing only with
things that need to be done for serial communication.  It started life
as a combination serial module and display, but as soon as the serial
part was working to my satisfaction, I split the display out and
started the second module, called (you guessed it), DispMod.  DispMod
was a simple display program having only one type of window, and only
enough functionality to be able to handle keyboard input and text
output.

    By itself, SerMod is somewhat limited. You can run it from a
script, and send it commands from the script, to do a variety of jobs,
such as setting the serial port parameters, sending text, receiving
text, and checking for matches with user defined strings on the
incoming data.  With an appropriate script, it could act as a file
transfer utility, a BBS, or a program to allow remote CLI-like
operation of your machine (in a limited manner). With the addition of
DispMod, the combination of a script, SerMod, and DispMod become a
fairly powerful terminal program.  When I say 'fairly powerful', I
refer to the complete scripting capability provided by ARexx, since
the protocol modules, menu module, gadget module, and so forth, have
yet to be written.

    I chose to write SerMod first, since many programs can benefit from
serial communication capability, and because it is not difficult to
visualize ways in which you can combine a serial module with other
programs. SuperBase is about to arrive (it may have already), with an
ARexx interface, MicroFiche Filer already has one. CygnusEd
Professional, TxEd, UEdit, and DME all have ARexx interfaces.  PCLO
and PCLO Plus have one.  With SerMod and an ARexx program, any of
these programs have suddenly acquired the ability to communicate over
the serial port, locally using a null modem cable, or remotely via modem.
If there is enough interest in this project, there will undoubtedly be more
modules written, small programs that do only a few things, and that allow you
to custom-build other applications.  Even those who have no desire to program,
even in ARexx, can benefit from the ARexx programs written for ROBBS.

    Perhaps a few words about the philosophy behind ROBBS modules would
be in order.  ROBBS stands for Rexx Object Building Block System.  A
typical ROBBS application will consist of one or more ROBBS modules,
controlled by one or more ARexx scripts. In addition, other programs
might be called, whether or not they actually have an ARexx interface.
Any program that can give you the data you need, perhaps in a file,
can be used with an application.

    Each module in a ROBBS application should do only a few operations,
to keep the size down, to simplify programming, and to ensure that
there is little duplication of effort between modules. Only those
commands that make sense to the particular application need be
provided. There need be no 'standard' set of commands across all
modules, for the above reason, and because it is easy enough to change
the controlling ARexx program to account for any differences. There
are a few commands that make sense to all modules, and these should be
called by the same name in all modules. Examples of these are STATUS,
CONNECT, CTRL, and DIE (more about these later).

    At this time, I'd like to give you an overview of what a typical
module might look like from an ARexx programmer's point of view, and
I'll use SerMod as an example. Though it is 'finished', it is not
'cast in stone'. If you have any suggestions for additional features,
I would like to hear about them.

                        -----

             Commands that SerMod understands:

RXD - Turns the serial received data on or off.  This is to allow
      other programs that open the serial port in shared mode to have
      access to it without interference.  Accepts 'ON' or 'OFF' as
      arguments

TXD - Enables or disables transmitted data. Allows another program to
      send data without any interference from Sermod.  The other
      program must open the serial device in shared mode. Accepts 'ON'
      or 'OFF' as arguments

SEND - Send a string out the serial port. A variation of this command,
       LSEND, sends a string with an appended Carriage Return character.
       Accepts a string as an argument.

MATCH - Sets up a 'match string' for Sermod to watch for in the
        received data.  When a match is detected by SerMod, a message
        is sent to the CTRL port, specifying the number of the string
        that matched.  Sermod allows 10 strings of up to 100
        characters each, and the MATCH command can be issued any
        number of times, which means that you can replace any match
        strings already set up.  MATCH also lets you clear any
        matchstring, or clear all matchstrings. Note that SCAN must be
        active in order for a match to have any effect. Accepts a
        number between 0 and 9, followed by a string as an argument.
        Example: MATCH 3 'This is a string'


SCAN - Enables the matching of received data with the MATCH strings
       currently active. Takes either ON or OFF as a parameter.

CONNECT - Connects the received data with a named message port.
          CONNECT also lets you set up the command that will be used
          to send the data, since not all modules have the same
          command for receiving data.
          Sometimes you might want the controlling script to receive
          all incoming data, while at other times you would want the
          data to go directly to another ROBBS module.
          Accepts two arguments, a port name and a command.

CTRL - Connects Sermod to another port for control purposes. While any
       script program may send messages to Sermod, Sermod sends
       received data to the 'CONNECT' port, and 'matched' messages to
       the controlling port. This means that you can pass control from
       script to script, as you see fit. Accepts a port name as an
       argument.

COMM - Lets you set baud rate, mode (echo, noecho), handshaking, and
       translation (7 or 8 bits for received data). See detailed
       command explanation for a complete discussion of arguments
       required.

DIE - Commands Sermod to quit and unload from the system. If all
      messages sent from Sermod have been replied, this will be done
      immediately.  If there are any outstanding unreplied messages, a
      message will be printed to the CLI from which Sermod was
      launched to that effect, and you must then issue the REALLY_DIE
      message to remove Sermod.  This shoudl never happen in a
      debugged application, and is provided as an emergency escape for
      the times when a script terminates early due to an error.
      Needs no arguments.

STATUS - Returns a string consisting of the current status of Sermod.
         It contains information on serial port settings, the SCAN,
         TXD, and RXD state, the CONNECT and CTRL ports, and, for
         future use, the address of the IOSerial Request structure
         Sermod is using. Needs no arguments. See detailed command
         description for format of returned status string.

                           -----

This introductory text appeared originally in Transactor for the Amiga.