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?
_______________________________________________
This is the Linux 5250 Development Project (LINUX5250) mailing list
To post a message email: [EMAIL PROTECTED]
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/linux5250
or email: [EMAIL PROTECTED]
Before posting, please take a moment to review the archives
at http://archive.midrange.com/linux5250.
