Here are resoponses to some requests for clarification from Jay Martin.
>> Here are proposed prtChannelInformation definitions for selected
>> PrtChannelType values:
>>>> chLPDServer(8), -- ...
>> -- prtChannelInformation entries:
>> -- printer queue name
>> -- name: QUEUE, mandatory, single value
>> -- value is the ASCII queue name as
>> -- described in RFC 1179
>> How do you propose specifying multiple LPD queues? Should the implementor
> provide multiple channel type entries (in which the singular QUEUE name
> is specified on a per-entry basis)? Or should the QUEUE keyword be allowed
> to have multiple values?
Each queue needs its own Channel Table entry. Each queue is a different
channel for providing data to the printer, and each may have distinct
settings for the items in its Channel Table entry. For instance, it's
very likely that queues will have different values for
prtChannelDefaultPageDescLangIndex.
> Also, we had (privately) discussed the notion of defining "well-known"
> LPD queue names to effect common services types, for example:
>> "Raw" The print job data is processed "as is" with no translation.
>> "AutoCR" Any linefeed character encountered in the job data stream
> will have a carriage return character automatically inserted
> after the linefeed character.
>> Should we bring up this topic now while the MIB spec is in flux?
Every time we start digging into lpr/lpd, I get depressed. But here are
a couple of thoughts:
1. One would like to be able to answer the question "What sort of print
jobs can I submit on this channel."
2. RFC 1179 job submission specifies subcommands that designate how the
data in the job is to be handled. These correspond vaguely to
PrtInterpreterLangFamily values, but with an eclectic set of
choices:
Caltech Intermediate Form plot data
TeX DVI data
formatted text
Berkeley Unix plot library output
data with control characters
ditroff output data
PostScript
data to be formatted with pr
FORTRAN carriage control
troff output data
SUN raster format data
For a while, I considered whether the prtChannelInformation item for
a chLPDServer channel should specify which of these settings were
allowed by the queue. But the list of choices bears so little
relation to current practice that there seemed little benefit.
3. Current practice seems to be more in line with what Jay described
above, where the queue name is linked to some data type or set of
processing conventions. But each vendor has their own choice of
names.
4. Rather than trying to codify queue names, I'm now tending toward
using the prtChannelCurrentJobCntlLangIndex and
prtChannelDefaultPageDescLangIndex items to characterize the print
jobs allowed by the channel.
Jay's "Raw" example would have appropriate interpreter index
settings for job control language (a langPSPrinter or langPJL
interpreter, for instance) and default page description language (a
langPS interpreter, for instance). The "AutoCR" example is more of
a mess -- it needs a control language setting of "none," which
doesn't seem to be an available choice, and an interpreter index
setting for its default page description language that might be a
langLineData or langSimpleText interpreter (or a new enum value).
Has the idea that a channel might not have job control been
considered? And is there a language corresponding to the UNIX-style
interpretation of ASCII newline as linefeed (ASCII carriage return /
linefeed)?
>> chDECLAT(32), -- ...
>> -- prtChannelInformation entries:
>> -- port name
>> -- name: PORT, optional, single value
>> -- service name
>> -- name: SERVICE, optional, single value
>> -- Exactly one of port and service must be
>> -- specified.
>> The last sentence is a bit confusing. Are you saying that only ONE of
> the defined keywords can exist in the value? Actually, the text makes
> it sound like a chDECLAT channel type MUST specify either the PORT or
> the SERVICE; that is, neither keyword is really optional. Can you clarify
> this?
I was trying to get too economical with words. Try this:
-- Port and service are mutually exclusive;
-- one must be specified, but not both.
So, yeah, each one is conditionally mandatory (;-), if you want to put
it that way. I figured that, considered individually, each was
conditional, but there was an additional constraint when the two were
considered together. Perhaps if we used the more structured format you
suggested in another posting, the entry would say "see below," rather
than "optional." I think, in general, there will be interactions like
this that just have to be spelled out in descriptive text.
:: David Kellerman Northlake Software 503-228-3383
::david_kellerman at nls.com Portland, Oregon fax 503-228-5662