It's possible that a client might make assumptions that the two chLPDServer channel rows would be completely independent, and in
most, if not all, implementations I know of, that's not the case. There's only one LPD server in the printer, and it can forward
jobs to one or more queues, depending upon which queue is specified.
In my previous comment, I was asking for a change to "allow" multiplicity". Implementations are still free to instatiate multiple
chLPDServer rows as well.
Randy
David_Kellerman at nls.com wrote:
> > I noticed in the channel group that LPD servers can only have one
> > queue associated. The "Multiplicity" specification is "single". This
> > implies that for printer-resident LPD servers that want to support
> > more than one queue, that multiple channel group rows would exist
> > (multiple instances of chLPDServer) ?
>> Right.
>> > Was this what we were thinking? Or would changing the "multiplicity"
> > capability of chLPDServer to "multiple" be easier. I'm not sure why
> > we just didn't use "multiple", since this still does not preclude
> > an implementation from still having separate row instances of
> > chLPDServer. But at the same time, it saves redundant rows in the
> > table when a printer only wants to expose very few queues, say just
> > 2 or 3.
>> I believe we discussed this at the time, and it was a conscious
> decision. As the comment at the beginning of the Channel Group
> says, "channels are independent sources of print data." I take this
> to mean one channel table entry, one independent source of print
> data.
>> Otherwise, you end up with multiple potential representations for
> the same configuration. This increases client complexity and the
> likelihood of clients not handling all alternatives correctly.
>> Besides, I can't see where you can really use this -- remember, if
> two queues have different prtChannelCurrentJobCntlLangIndex,
> prtChannelDefaultPageDescLangIndex, prtChannelState, or
> prtChannelStatus values (which seems pretty likely), they need
> separate entries.
>> > Would the scope of this change be possible given our current state
> > of the document?
>> It would be a mistake to make the change.
>> David
>> :: David Kellerman Northlake Software 503-228-3383
> :: david_kellerman at nls.com Portland, Oregon fax 503-228-5662