Amiga Elysian Archive/AmigaElysianArchive.iso/prog/utils/sercli.shr/sercli/doc/ToDo

Text File | 1993-06-14 | 14.8 KB | 332 lines

**  Fix EOL translation to be smarter on data received from the .device &
    add translation code for FIFO->.device

    In the same breath, could make EOF a configurable key, rather than
    binding ^\, and allow for arbitrary i/o translation tables...

**  Currently, all data from FIFO is immediately put into a buffer
    (allocating one if necessary) and that buffer is sent to the .device.

    The buffer is of fixed size.  No effort is made to glom multiple chunks
    of data from FIFO into a single .device i/o request.

    This obviously is going to be bad for memory fragmentation (only a few
    bytes used in large buffers attached to IOExtSer structures), and may
    be bad for performance (by creating a bunch of i/o requests
    w/relatively little data).

**  FIFO EOF has two big problems:
    **    Current mechanism (close_fifo() immediately followed by an
    open_fifo() ) results in a way-ward FIFO connect.  For some reason,
    it works okay if I exit sercli & restart, but just doing the
    close_fifo()/open_fifo() isn't enough.  It's possible that there's
    a consideration of time-delay...

    **    Whether you call the above a bug, per se, in sercli, I can almost
    certainly fix it.  However, another problem exists: EOF is only
    generated by FIFO if _all_ writers have closed the FIFO and at
    least one used the FIFOF_EOF flag when closing.  As long as I have
    a RemCLI open on the same FIFO as sercli, FIFO will NOT generate an
    EOF for sercli, thus CD/^\ events cannot be reliably handled with
    current FIFO versions.    If a new version of FIFO cannot be had to
    fix this, I may have to simply use DOS Packets.

**  Add a ^C (or some such) check to sercli so that it can be aborted at
    any time even without ARexx or Intuition access to it?  (By `^C', I do
    not mean the .device<->FIFO i/o monitoring; I mean look for a
    SIGF_BREAKC (or whatever) signal, of course.)

**  Add controls (via both config & ARexx) for turning on/off the ^[c-f]
    DOS breaks.  Relatedly, add ^\ -> EOF conversion.  Lastly, monitor CD
    (OPTIONALLY); if CD is gone, then do something drastic like send all 4
    standard break signals, SIGF_ABORT, and an EOF all in concert.
    [CD should now be monitored; currently only generates an EOF, and
     then not correctly (see above); also have done ^\ -> EOF
     conversion, but have similar problems.]

    (This somewhat ties into the later (chronologically earlier) suggestion
     of `on: serial: no carrier: ...'.)

**  This file is disorganized.    Maybe I should experiment with putting it
    into HyperText form?  *grin*  (Or else re-structure the thoughts I
    ramble on about...)

**  Make naming conventions more consistant.  In particular, make the
    serial.c functions all of one form (e.g., <verb>_<noun>_<modifier>,
    such as open_ser(), write_ser_asynch()...)

    Clean up the names in the source (the serial.c file was mostly written
    over a period of about a week, last spring, and I picked at least one
    or two truly horrible names for types/variables...*grin*).

    (Mostly satisfactory, for now...)

**  Add some kind of intelligent error handling for i/o...

    (Started already; see errors.[ch].  Not really ideal, but will work for
     my immediate needs.)

    (Mostly staisfactory, for now...)

    (However, a generic event-handler, or my rkr.lib is pro'ly next up; it
     could then become the ARexx/config/error handler for sercli.)

**  XPR support...

**  Make sercli _not_ exit when an EOF comes down the pipe (FIFO:).
    (Shouldn't be too hard to add.)  This way, programs can be run to use
    FIFO:, and after they terminate, sercli will persevere.  The point is
    to permit the "main" program to use ARexx i/o, if desired, but to
    launch other programs (such as a compiled C or interpreted LISP or
    SCHEME program) as plain stdio users; when the "plain stdio users"
    exit, the "main" program can resume, safely assuming that sercli is
    still around.

    This of course requires that an ARexx command be defined ('quit'?) to
    cause sercli to die alogether.  Relatedly would be serial i/o support
    directly through ARexx message ports, and control of who sees how much
    of what. See elsewhere.

    Alternative/intermediate fix: Don't use the 'e' flag with FIFO:.  By
    not using the 'e' flag, FIFO: will not pass the EOF event on to sercli,
    and so sercli will not notice.  Note that sercli will still try to send
    stuff through FIFO:, and FIFO: may conceivably back-up and overflow.
    Controls to cause sercli to stop sending data to FIFO:, and to avoid
    overflow problems, need to be put in eventually.

    [No, this isn't necessary; just use rlaunch to run programs under
     sercli; that way, when they end their shell, FIFO can keep on
     going.]

**  ASK on AMIGA_PROG if {io_Baud} (etc.) can be set on open, or only by
    SDCMD_SETPARAMS.  (1.3 autodocs describes SERF_XDISABLED as being the
    only bit "that can be changed via a SetParams call while the device is
    active," while L&D states that it (along with SERF_SHARED and
    SERF_7WIRE) "must be set before open."

    Related: It does not seem that all serial configurations are being set.
    I need to try a SDCMD_QUERY, and see what that brings me.

    ---

    Asked; response was not of much real (authoritative) help.

    ---

    Also, error-handler does not handle cases for serial error being
    out-of-range (a table of 15 codes (1-15), taken from RKM:L&D, is used;
    if a too-low, or too-high error code comes through, the results are
    undefined.    (This is not so much a problem with serial.c as with
    sercli.c, although perhaps I should toss the serial error-handler into
    serial.c...)

**  Buffer FIFO: to avoid problems with blocking i/o?

**  Make i/o available through the ARexx port (rather than, or in addition
    to, through FIFO:...provide _both_ streams to the script?  (on script's
    request?) ), in one manner or another (right now, all programs must use
    FIFO:, which I've found results in some weird necessities for clean
    launch/cleanup).

    I should, then, be able to provide a "timeoutable" read command, which
    would be very cumbersome to implement through ARexx scripts using stdio
    (not impossible, though)...

    Additionally, being able to "turn off" serial output, serial input,
    FIFO: input, FIFO: output, and even the ARexx port input & output would
    be a nice feature (thus, a "master" ARexx script could turn off it's
    own input from sercli, launch a shell command, and turn on the FIFO:
    i/o, then wait for the program to complete, whereupon it would disable
    FIFO: i/o, re-enable its own i/o, and pick up where it left off).

    (Turning "off" ARexx input does not mean that additional commands
    (e.g., turning ARexx input back on, "bps: <n>", etc.) would not be
    honored, only that no input from the modem could be received through
    the ARexx port, even when requested, until ARexx input is turned back
    on...)

**  Make a command/config option for setting the _format_ of the displayed
    text line, plus selecting the "visual flags" to display.

**  Commands have been advanced somewhat.  See above for idea about
    allowing ARexx commands to handle the i/o as well as permitting stdio
    (stdio has several limitations that an ARexx command interface need not
    be bothered with.)

    The below list does not represent the current set of commands (a set of
    serial config commands are supported (but not much tested) ).

    ---

    Right now, the ARexx commands are in a disarray.  What is desired is:
    set remote status: <remote status>
    set window size: <x> <y>
    set window position: <x> <y>        ;; really need this?
    set window title: <full title>        ;; really need this?

    Could also convert into functions, or at least get rid of the ':' char.

    Each would return a string to represent the 'old' information (the old
    remote status, the old x/y position, etc...).

**  ISSUE:  There were, once, synonyms for many of the keywords supported
    (e.g., "bps" and "baud" were treated identically; now, only "bps" is
    supported and "baud" should cause an error). Would it be desirable to
    put the synonyms back in?

**  [Hmm...  I think I _do_ want to use a serial-init structure, despite
     the immediately-following comment.  It would make serial.c independant
     of sercli, as it should be. [further thought: No, use ANSI C variable
     args on the stack...much better] ]

    Change open_ser() to take a pointer to a serial-init structure (and put
    "globals" in there, so that multiple ports could be open
    simultaneously?  Hmm....that would require giving a param to
    close_ser(), as well...).  (NO, just run sercli multiple times!)
    (Globals are used for the config controls.  Maybe eventually put this
    stuff in a clean structure (or IFF FORM (is FORM the right thing for a
    config file, necessarily?) & use a binary config file (set with an
    Intuition-based tool, like jconfig, jinit, or Preferences).)

**  [This may go in at the same time I allow the ARexx port to reconfigure
     its own name & the fifo name...  Which means I might do it. *grin*]

    Perhaps allow ARexx script to cause sercli to shut down serial.device &
    reopen under a new device name/unit?

    (Really trivial to add this, since "hard" parameter changes already
    require that the serial port be shut down...)

**  Some kind of control for what to happen if we lose carrier...?
    on lost carrier: <command>

    Or something more generic, even?
    on string: <string>: <command>
    on event: <event type>: <response>
    on: <general>: <specific>: <response type>: <detail>

    Examples of the last may be:
    on: serial status: no dtr: sercli: exit
    on: serial string: CARRIER DETECT: rexx: launch_bbs.rexx
    on: serial string: name?: send: Richard Rauch
    on: window event: close: sercli: exit
        (This would exclude ':' from occuring in the <string>s, unless
        things were made substantially(???) more complicated...)

        Or just have sercli send up a BREAK (^[c-f]) and assume that
        the program running under the shell will know what to do?

        The problem with responding on certain strings is that for
        every byte that comes in, checks would have to be made to see
        what state to put things in.  With several strings being
        monitored, this could slow things down.  One _could_, of
        course, assume that the text-to-check represents a whole line,
        or the tail-end of a line...or perhaps not-so-cumbersome state
        machine could be set up to handle it...

        Or, assume that these (at least the string responses) are
        always to be to prompts from a BBS, so we could only need do
        such a check after a pause in the input stream, and then only
        on the last line (or last <n> bytes/lines?).

        Some way of turning off these on:... events is needed.  I think
        something of the following form would be a desirable way to
        remove the "event monitor" for an inbound serial string of
        "name?":
        on: serial string: name?: nop:

        (Note, one "fewer" params/keys, here.  After "nop:", nothing is
        needed (no detail is needed for a "nop:").

        Possibly, some others (like exit) could be placed in the same
        sense as "nop:".  Also, perhaps it would be a good idea to
        fully endorse the idea of trailing colons being unecessar (so
        long as there are no spaces between the last keyword and the
        eol).  Perhaps also cause colons to be always used as
        delimiters.

        (This would suggest allowing an "escape" convention for
         colons...)

    I suspect that all of this is getting _much_ too general for what I
    want to do, but it's a thought to keep in mind, at least for now.

**  Change how config stuff is handled so that config & ARexx commands can
    dispense with the ':' character (as a special character, anyway).

    On the other hand, a colon is as good as any other character for
    delimiting tokens -- unless one forces the user to enter all tokens as
    single words or has a rather elaborate command processor.

**  Some visual flags to represent the serial line state?

    Also make the window default to 640 pixels across?

**  Change program name to sersh or sershell?

**  Maybe the line-oriented serial read should support some line-editing
    (like allow <BACKSPACE> to remove chars from the buffer, and ^x to
    clear the entire buffer).

    NAH.  Let the FIFO:, or shell do that cooking.  Maybe when (if)
    serial.c gets split off into its own .lib, this would be worth doing.
    Not right now, though.

**  Handling of serial.c defaults is pro'ly not correct, as I think on it.
    I.e., sercli's internal defaults are rammed, unconditionally, into the
    serial.device via SDCMD_SETPARAMS.    This means that Preferences
    settings will always get overridden with internal sercli defaults
    (whoops).

    I should address this either by using taglist type things, or else by
    using flags to indicate what is to be set/not set.

    Relatedly, after setting serial params, all i/o requests should pro'ly
    be updated with the new contents; not sure, but it can't hurt much.

    Parity and hardware/software flow control handshaking defaults should
    be changed to be defaulted by Preferences (and DOCUMENTED as defaulted
    by Preferences...)

**  Remove some globals (particularly serial.c's configuration globals, but
    perhaps others as well...).

    This would be in preperation for breaking portions off into a seperate
    .lib.

**  Make read_sercli_config() take a file name param, so that it can be
    completely generalized, and used as readily in `sercli' as in a `door?'
    Also change name to read_config()?

**  Break out serial.c, and others, into a seperate dir (make part of
    a custom lib) so that their maintenance can occur external to sercli.

**  Break up sercli.c and maybe serial.c; they are a bit on the large side
    for my taste.  (Clear some junk out of main(), by putting some func's
    in other files, maybe put all the fifo handling stuff in a fifo.c
    file?)

**  RCS maint. is not yet tested.  It should no longer _force_ all files to
    be re-done.  Different RCS files should be permitted to have different
    RCS versions & still retain the same symbolic name.

    The `changes' files are no longer used as automatic references for RCS
    `update messages'.

    The biggest problems:
    **    No automatic version bumping, yet (aside from the "meaningless" ?.?
    numbering that RCS does for every ci).    Fortunately, esssentially
    only one symbol ({name}, in the src/dmakefile) need be manually
    updated.

    I dislike having to modify the dmakefile just to update the
    version-number; I should export the version info permamently into
    some other file, I guess...

    **    Because some info is duplicated across more than one "changes"
    file, the doc/changes.text file can have a lot of redundancy if not
    manually trimmed.

    (E.g., the FifoName string was in a series of files; converting it
     to prog_id affected several files...)