Re: Minor updates in CVS

The approach that I was originally suggesting only entailed calling
functions.  That approach should be accepted on every platform.

Apparently, I didn't get my idea across, so I'll elaborate.

There are really only 4 different "events" where lp5250d needs to interact
with the output device.  they are:

       1) At the start of a new document.
       2) Each time a character was received from the AS/400.
       3) At the end of document.
       4) When an error message occurs that needs to (somehow) be
            sent to the user.

Right now, in lp5250d, these actions are hardcoded into the lp5250d code
itself.   They do a popen(), fprintf(), pclose() and syslog()
respectively.

My suggestion, was to create a "class" (actually, a struct, since this is C)
which contains pointers to each of these functions.   This would allow us
to write modules (such as scs2ascii, scs2pdf, scs2ps).   To "attach" a
different module would only require setting the pointers in the structure
to different values.

This is the method used for "streams" in Tn5250.  This is how it's able to
attach to the "ssl" stream instead of the "telnet" stream.   We also use
this method for "terminals", so that we can have a ncurses terminal, a
gtk-terminal, a S/Lang terminal and a Windows terminal and a debug
terminal all using the same program.  We just "attach" to whichever one
is appropriate for the task at hand.

You could even keep scs2ascii, scs2pdf, scs2ps as seperate programs from
lp5250d on Unix systems.   Just have lp5250d attach to the "output to
pipe" printer method, and then have scs2ascii call the scs2ascii routines
for each character received from the pipe.  (the same for scs2ps or
scs2pdf as well)

But, on Windows, I could attach to the scs2xxx routines directly and not
worry about the pipe issues...

On Tue, 19 Mar 2002, James Rich wrote:
>
> > Pipes work, they're just slow.  TCP sockets would work, but would require
> > changing the way scs2ascii & friends work, which is what James appears
> > to be protesting against.
>
> Actually I'm just trying to find a method that works well for all
> platforms.  Right now the unix version uses a pipe and the windows version
> doesn't.  I'm trying to figure out how we can make both versions the same
> (or at least very similar - meaning maybe lp5250d is different on each OS
> but then scs2ascii etc. are the same on all platforms).
>
> I'm not trying to protest anything, just figure stuff out.
>