Re: [Lpr-discuss] gnulpr requirements

[<dn...@le...>]

Ben, at al.,
(Pardon the lack of inline quoted reply -- I'm stuck using horrible Lotus Notes
at work :-(

For filter pipelines, I was thinking that each filter would inherit an extra
filedescriptor that's open directly to the printer, so filters would not need to
pass printer replies back via earlier filters in the pipeline (this also
bypasses the problem of each filter needing to figure out if the reply from the
printer was meant for it).   We also need to figure out if this extra fd should
connected to the printer's data channel or to its command channel; or maybe we
need two fd's, one for the data channel & one for the command channel.  I just
realized that there is also a potential timing/race issue: some filters may need
to talk directly to the printer to do setup functions before other filters
output their first datastream data.

For error notifications, I was likewise thinking that each filter would inherit
an extra "filter error" filedescriptor that's opened back to the print
subsystem; various messages generated by a filter and it's subprocesses would
get recorded to the stderr log, but true error messages sent to the "filter
error" fd would need to be in a particular format to indicate the filter name,
severity, and error description.  (I'm stealing this concept from the "lp.tell"
facility used in the Solaris lpsched model/interface scripts.)

By using pre-opened fd's, filters can easily be a shell script.  For example, if
the fd directly to the printer is fd4 and the error fd to the print subsystem is
fd5, a filter might contain something like

     #-- Get the current status
     echo "@PJL INFO CONFIG" >&4
     while [ 1 ] ; do
          read foo <&4
          if [ "$foo" = "\f" ] ; then
               break
          fi
          #-- Parse a result line
     done
     if [ "$config4" != "duplex" ] ; then
          echo "configcheck-filter 1 Error: Printer does not have a duplexer
installed" >&5
          exit 9
     fi

Concerning non-PS input:  For efficiency, I'd like to be able to avoid an
unnecessary conversion to PostScript.  (The worst case would be to have PCL
input converted to PS, then converted back to PCL for delivery.)   Another
reason is that some printers (including Lexmark lasers) have an option to accept
plain text and then map text fields into pre-defined forms; always to converting
to PS would break this functionality.  (As you'd expect, businesses use this
instead of home users.)

Concerning multiplexing of print path data and control commands:   I was
envisioning that this filter might use PJL USTATUS rather than SNMP, since PJL
USTATUS gives asynch notifications (which is better than SNMP polling) and it
works on both network (TCP port 9100) and local-attach connections.   This same
filter would also be able to accept queries/commands from management/status
clients via IP connections.  For this reason, this multiplexor might need to be
running all the time as a daemon (one for each defined printer?) instead of
being a filter that's started/stopped for each delivery.

-david

David Nessl
Lexmark