I've posted this feedback in slide form at:
This feedback is based on my work on IPPSIX, the IPP binding spec for this stuff...
- Don’t like being able to get jobs for multiple Printers
- Doesn’t match existing SM or IPP Printer objects - the Client
is always talking to a single service endpoint/target, not
- Existing model does not preclude having a Cloud Print Manager
that fronts multiple output devices
- 1 Cloud Print Manager with multiple output devices
sharing the same Cloud Print Service, or
- N Cloud Print Managers (implementation might merge
these) each using their own Cloud Print Service
- But why have GetAvailableJobs at all?
- Existing GetJobs operation provides all the info needed
- Notifications tell you which printer needs to be polled
- Need basic transform functionality
- Request that the document data be transformed to a
suitable format for printing, such as “I need PWG
Raster data in 8-bit grayscale at 300dpi”
- This is used by Google Cloud Print and other
- Also covers things such as copy generation, scaling,
- Cloud Print Service advertises capabilities
- Cloud Print Manager includes DocumentTicket in FetchDocument
- Includes additional elements for output format
- Cloud Print Service will need to fetch data from
- Do we define when that happens?
- What about caching?
User Role “Printer”
- When characterizing access control policies, we often use
“adminstrator”, “operator”, “user”, and “system” as user
- For Cloud Print we need a new role for the printer/ Cloud
- Printers can fetch documents, users probably can’t
(although there is a use case for users viewing
documents they have submitted...)
- Most of the other Cloud Print operations are probably
Michael Sweet, Senior Printing System Engineer, PWG Chair
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...