Comment 18 for bug 1747759
Revision history for this message
| Till Kamppeter (till-kamppeter) wrote | #18 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
a60fb26
(Get the code!)
[Security]
- does parse data formats as users print "through" this lib. And files/content
could come from anywhere - I'd consider this an untrusted source.
It only passes through the actual print job content, it neither parses nor converts it into another format. The library only handles meta data, polling the backend (which in turn polls the print service, like CUPS) to get printer capabilities and options, and passing them on to the print dialog to get displayed there, and passing the user's selections for these options along with the job back to the backend (which in turn adds them to the job as metadata/job ticket, according to the needs of the print service).
[Common blockers]
- This does not need special HW for build or test (only the backends
might need that)
Theoretically one could create a backend which talks directly with a printer or a print server appliance, having some kind of non-standard printer driver (not endorsed by OpenPrinting, standard are Printer Applications), but such a backend is never required to be able to test this library, as there exist already 2 backends not reqiring special hardware: cpdb-backend-cups and cpdb-backend-file. Especially cpdb-backend-cups should exercise cpdb-libs in practically all aspects.
[Upstream red flags]
- part of the UI, but not an app, so it does not need a desktop file
It does not actually provide a user interface, it only manages data which makes up user interface elements (in the print dialog).
- no translation present, interestingly given that it is meant to be helping
wit hprint dialogs. But it is really just a man in the middle. Providing
interfaces and a connection between frontends (have the translations) and
back ends (have the functionality). So this should be no problem.
It supplies UI strings to the print dialog, translations are currently not supported but will be supported in the 2.0 version. The translation themselves will be provided by the print service (like CUPS) and carried through by the backends and cpdb-libs.