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@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@nls.com Portland, Oregon fax 503-228-5662