Add D-Bus interface support

[michaelrsweet]

The CUPS local server will provide a D-Bus interface in addition to the traditional domain socket. Add support for sending/receiving IPP requests and responses over D-Bus.

[michaelrsweet]

D-Bus Printing API

Methods (that correspond to IPP operations):

⁃	Get-Printers
⁃	Get-Printer-Attributes
⁃	Get-Jobs
⁃	Get-Job-Attributes
⁃	Create-Job
⁃	Send-Document (reads document from passed file descriptor)
⁃	Create-Local-Printer
⁃	Cancel-Job
⁃	Cancel-Jobs

Functions:

ipp_t *_cupsDBusToIPP(DBusMessage *msg);
DBusMessage *_cupsIPPToDBus(ipp_t *ipp);

Map between encodings. Service is “org.cups.local”, path is “/org/cups3/print/printer-name” or “/org/cups3/system” (based on IPP resource path). Method is IPP operation name.

Single argument - array of dictionaries, first key/value pair is “g” and a byte for the group tag. IPP “attributes-charset”, “attributes-natural-language”, “printer-uri”, and “system-uri” are stripped.

[michaelrsweet]

This might be better hosted/implemented in the cups-local project since that is the only user for this at present...

[michaelrsweet]

Actually, I think we just want one "StartServer" method which returns the domain socket to use for the current user. Then the rest will continue to go over the socket and D-Bus can handle starting/stopping the per-user instance.

[michaelrsweet]

Tracking the libcups work for this in libcups issue #69.

[michaelrsweet]

[master a485e44] Add D-Bus service support (Issue #1)

[tillkamppeter]

This might be better hosted/implemented in the cups-local project since that is the only user for this at present...

@michaelrsweet I would like to have the D-Bus interface back in the libcups3 API, as I want to re-use it. I want to replace the D-Bus interface which the Common Print Dialog Backends (CPDB) use by your D-Bus interface for CUPS.

This has the following advantages:

• The original D-Bus interface of the CPDB has some problems, in efficiency, security, and sandboxability/snappability. Yout IPP-over-D-Bus interface will probably solve most or all these problems. See this thread in the snapcraft.io forum, especially the last postings from @JamesH .
• It does not make sense that we maintain 2 D-Bus protocols for printing jobs, including selecting the printer, setting the options, and checking whether the job got done, at OpenPrinting.
• As soon as the local server of CUPS 3.x gets available we do not need a CPDB backend for CUPS any more as the local server will be the CPDB backend by itself then.

[michaelrsweet]

@tillkamppeter libcups3 will use the D-Bus API exposed by cups-local to get the per-user domain socket to use to talk with cups-locald. Wrapping IPP requests (including potentially gigabytes of print data) in D-Bus messages won't work (I did try prototyping it but D-Bus isn't made to send large messages...)

Nothing will prevent cups-locald from also providing a D-Bus API for showing a print dialog, etc., but the point of this interface is to allow libcups3 to safely discover the per-user domain socket for programs that don't use CPDB.

[michaelrsweet]

From the daemon/dbus.c file:

//
// The D-Bus API is used to start cups-locald and return the proper Unix
// domain socket to use.
//
// node /org/openprinting/cupslocald
//   interface org.openprinting.cupslocald
//     methods:
//       GetSocket(out s socketpath);
//