Re: scripting tn5250

Hello Steven,

On Fri, 11 Oct 2002, Steven Kurylo wrote:
>
> >Personally, though, I'd like to either see the existing macro support be
> >extended, or I'd like to see a somewhat more external way of handling this
> >(such as opening up a telnet session in your program, and using that to
> >control in the input and output, or writing a separate terminal object for
> >the emulator that works similarly to the way the debug term works... etc)
> >
> >
> Well thats why I'm asking for opinions, because I'd prefer this to be
> general enough that it benefits everyone.
>
[SNIP]

> All help is appreciated.  I'd like to work out the best way to proceed
> and figure out a rough estimate for how long it should take.
>

Here's my thoughts on how to implement it.  Of course, your input is
welcome, even encouraged, because I may just be crazy. :)

But anyway, I'll try to explain what I have in mind:

    1)  If you take a look at tn5250.c, you'll see that if USE_CURSES is
           defined, it creates a new "terminal object" by calling
           tn5250_curses_terminal_new().   If USE_SLANG is defined, it
           will instead call tn5250_slang_terminal_new(), Likewise, if
           you look at tn5250-win.c it calls tn5250_win32_terminal_new,
           and gnome-5250 calls gtk5250_terminal_new().

         These terminal "objects" are connected to the rest of the
         5250 code in this way.  The "term" object that is returned from
         any of these functions is a structure that contains the information
         that each terminal needs to work.

    2)  Note that after the terminal has been set up, to checks to see
         if the remote host starts with "debug:"   If so, it will
         call tn525_debug_terminal_new() and pass the original terminal
         object as an argument.   What this is doing is telling the main
         codebase of tn5250 to call the terminal routines in debug.c.
         The routines in debug.c will in turn call the routines in
         cursesterm.c or slangterm.c or winterm.c or gtk5250terminal.c
         as appropriate.   This means that the debug code will work
         no matter which terminal you use, which is really nice.

    3)  What I'd like to see is something similar with the "remote control
         terminal".   After you've initialized the cursesterm or winterm
         or whatever you planned to use, if a config keyword says that
         remote control is necessary, you'd call tn5250_remote_new()
         and pass the terminal object as an argument.

        It would simply replace the "getkey" and "waitevent" members
        of the terminal structure with it's own routines.  Then, when
        it's own routines are run, it would call getkey and waitevent
        routines from the terminal object, thus allowing the user to
        continue to operate, regardless of terminal type, while still
        inserting its own keyboard input into the stream when necessary.

    4)  Naturally the bulk of the new code would go into it's own source
         file, maybe called "remotecontrol.c" or "tcp_remote.c" or something
         like that.

    5)  What I'd like to avoid is manually hacking changes into display.c
         session.c, and/or the various terminal-related sources.   There
         seems little reason to do this, and it doesn't really fit into the
         object-oriented design of tn5250.

    6)  Plus, by not changing the code inside display.c or session.c, etc,
         you run less risk of accidentally inputting data when the keyboard
         is supposed to be locked out, etc, which can cause the emulator
         to crash, or the program on the iSeries to crash.

    7)  It's also easier to "run without the changed code" if there happens
         to be a bug that would cause things to fail in some unexpected
         circumstance.


So, that's what I'd do.   What do you think?