[lsb-discuss] LSB futures tracker: Rendezvous

[Jeff Licquia]

On Mon, 2006-06-26 at 09:01 -0400, Theodore Tso wrote:
> On Fri, Jun 23, 2006 at 06:49:25PM -0400, Jeff Licquia wrote:
> > 
> > Right, but the issue with CUPS is whether the LSB should impose a
> > particular spooler's ABI on runtime implementations.  Must Solaris's
> > Linux compatibility layer, for example, include the CUPS ABI?
> 
> What ABI is being proposed to be standardized upon?  Maybe I'm missing
> something, but wouldn't applications do well just shell out to either
> /usr/bin/lpr or /usr/bin/lp?

The SysV and BSD command-line interfaces are very limited, according to
the ISVs we've talked to.  Submitting print jobs is fairly easy, but
querying print status and job status is difficult and requires us to
parse output we do not (AFAIK) standardize, and removing jobs depends on
querying job status to retrieve the job ID.  Plus, there is no standard
way of setting things like paper type, paper size, duplex mode, print
quality, or tray via the command-line interface.

All this is supported by the CUPS API, but currently LSB apps which want
to use the CUPS API must include a CUPS library in their app.  A lot of
vendors are not happy with this; they want to use the ABI provided by
the distros, which is generally stable across distros.  But if we do
this, we essentially canonize CUPS as "the LSB print system", which
might not be the best approach for non-Linux systems which have
different spoolers, or users who prefer other spoolers on Linux.

The Open Printing workgroup has created a generic API called PAPI which
should be a better candidate for standardizing, but it is too new, and
is not shipping in any current distros.  So, the question is: do we wait
for PAPI or add CUPS now?

As an additional wrinkle, the desktop projects also include APIs for
printing, which might also be good candidates for standardizing.