Am Freitag, 16. Dezember 2005 14:14 schrieb Michael Sweet:
Hi Michael,
> > It is a bad design decision for an application to directly link to the
> > cups client library (ABI concerns,...) but it is much better to use a
> > protocol based interface to use the full potential of CUPS.
>
> I strongly disagree with this, mainly because the CUPS API (and
> associated ABI) is very stable and will remain so
But it adds another runtime requirement to the application. When using
traditional linking this means that the application will fail at runtime if
the appropriate cups client library is not available.
> The following ASCII block diagram may be useful:
>
> +--------------------------------+
> | Application |
> +--------------------------------+
> +------------------+ +-----------+
> | Toolkit | | Print API |
> | +----------+ | |
> |
> | | +--------+ | |
> | |
> | | | RUDI | | |
> +-------+ +--------+ | |
> +--------------------+ |
> +--------------------------------+
> +--------------------------------+
> | Printing System |
> +--------------------------------+
+---------------------------------------+
| Application |
+---------------------------------------+
+------------------+ +------------------+
| Toolkit | | RUDI Print API |
| independent from | | Toolkit specific |
| DE used at | +-------+----------+
| runtime +----+ | +----+
| | wire | |
| | protocol |PAPI|
| | via dbus | |
+-----------------------+ | | |
| | |
+--------+ | |
| RUDI | | |
| Server | +----+
+--------------------------------+ +----+
| Desktop Environment | | |
| (offering a RUDI print service | |CUPS|
+--------------------------------+ +----+
I am trying to explain the situation from my POV. Basically the ISV
application shall only link to the toolkit of joice which in many cases is
not the toolkit of the desktop or a different version of the toolkit of the
desktop e.g. Qt/Java or gtk. In addition the application shall link to the
toolkit specific(*) RUDI library.
It is the job of the RUDI library to care for the abstraction of printing
systems and to provide the fallback to PAPI or as a last resort the "native"
toolkit specific printing mechanism (e.g. the native print dialog offering to
enter the print command like firefox does currently)
Basically this means that the RUDI lib first tries to find a suitable RUDI
server which offers the printing service and if this does fail for whatever
reasons PAPI is tried next.
(*) from a technical point of view the toolkit specific RUDI library is
provided for convinience reasons mainly so that e.g. Java programmers are not
exposed to a generic RUDI library written in plain C.
Regards,
-- martin
--
http://www.erfrakon.com/
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
_______________________________________________
Desktop_architects mailing list
Desktop_architects@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/desktop_architects
