[Omniprint-user] Re: [Inkjet-list] Re: Taking a step back

[Michael S. <mi...@ea...>]

On Thursday 27 December 2001 07:12 pm, Robert L Krawitz wrote:
> ...
> I'm generally in favor of a dynamic view of what the driver can do,
> because the constraints might be very complex, but this is an
> interesting thought.  However, why do we need an actual file in the
> filesystem (as opposed to some virtualized way of getting a handle to
> a PPD file)?  Do applications rely on open()/fopen() of PPD files, or
> is there some more abstract way of getting this information?

Well, the printing system layer could generate the file for the
client, however I'm pretty sure all existing clients need to
ultimately read the PPD file from an actual file, although the
KDEprint stuff might be just loading from the HTTP data, I dunno...

That said, there are enough existing apps that read PPDs directly
from files (e.g. StarOffice) that we'll need to support a static
snapshot file of some sort.  *How* that file is generated is a
design decision, however I know of two developers that are using
a background device daemon that monitors the print devices and
update the local PPD files for the current configuration.  I
suspect that this will remain the most flexible (i.e. least
printing-system centric) design...

> ...
> Extensions like this don't scale very well either; everybody will
> define their own extensions (look at what Cups-o-matic does; it uses
> structured comments in the PPD file to encode a perl data
> structure!).

Well, for CUPS-based drivers at least it will work, and other apps
will "see" the standard PPD file that will still work everywhere.

As for CUPS-o-matic, the perl data will almost certainly stay as
it is, but I'm pretty sure that the options can be updated to
use the new CUPS naming without a lot of trouble...

> ...
> I don't think we should think in terms of a single-threaded
> server-based driver, but having some way of querying the driver (even
> if it's a different process) would be useful.  I'm not convinced that
> we need to address this in the first go-round, but ultimately we
> will.

The problem is that in most cases you can't query the printer while
printing, and there are some major security issues with an app
talking directly to a device.  Better to define a common set
of attributes (there are a lot of them defined by IPP already)
that the driver can report to the printing system, which can
be provided to a client on request.  If you are monitoring the
device when not printing, the scheduler status data can be
updated on-the-fly...

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products                  mi...@ea...
Printing Software for UNIX                       http://www.easysw.com