cups use cases with IPPeve #635
-
Dear developers, I am wondering what use cases does cups solve with cups moving towards only talking to IPPeve-capable printers or drivers? Wouldn't it be simpler to just send the print jobs directly to the printer instead of talking via IPPeve to cups, which in turn talks to the printer using the same protocol? Cheers |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
@robertmx TL;DR: So there are reasons for this historically but for CUPS 3.0 we are actually looking at using D-Bus for local printing on Linux. Fundamentally CUPS needs to do the following:
Using IPP between the application and spooler is convenient because it minimizes the number of conversions needed and you can print to a local or remote print service with the same code. But as you note this isn't required just an implementation detail. For CUPS 3.0 we are looking at adding support for D-Bus (on Linux/*BSD) and XPC (macOS/iOS) as transports so that we can more easily fit in the "modern" security container architectures of these platforms and (more importantly) talk to a local print server running in the user's session so that per-user security credentials and other interactions happen in the user's session and not in a cupsd process running as root. If you look at the slides from the last OpenPrinting Summit you will see where CUPS 3.0 is going. |
Beta Was this translation helpful? Give feedback.
@robertmx TL;DR: So there are reasons for this historically but for CUPS 3.0 we are actually looking at using D-Bus for local printing on Linux.
Fundamentally CUPS needs to do the following: