I think it's been a feature of IPP, but I very rarely see it deployed by a customer -- CUPS may support it, but all my experience with IPP has been embedded IPP in the device, with no fan out.
I agree about the Kinko's case being a good use-case for fan-out, but this use-case (from the client's perspective) is probably easiest…it's kinda send and forget (except maybe an async notification (email, etc.) on final job disposition) -- no other auxiliary operations would probably be supported through a Kinko's UI.
I guess my issue is that for simple printing, it's probably ok…it's all the other permutations and combinations of operations that might have an issue. I've just never seen a large scale deployment where printers are hidden (completely) behind a proxy, from both a user and a remote admin perspective. In some designs, I've seen the physical printers hidden, but they are represented by queues, so there is some visibility.
On Dec 20, 2012, at 7:23 AM, Michael Sweet <msweet at apple.com> wrote:
>> On 2012-12-19, at 10:47 PM, Randy Turner <rturner at amalfisystems.com> wrote:
>> Hi All,
>>>>> From the face-to-face meeting in Irvine, and the discussion regarding how the print-manager works, I think we said:
>>>> 1. The print manager can host 1 physical printer or multiple printing devices.
>>>> 2. In the case of a print manager hosting multiple printing devices, it's acting as a "proxy" for communicating with the cloud.
>>>> If this is the case, I believe the print manager should ALWAYS expose each physical device to the cloud -- I think the proxy application should
>> operate on a 1-to-1 basis, and not a 1-to-many basis.
>> FWIW, the Semantic Model supports both architectures, and IMHO we need to support that in Cloud as well. Particularly for the print service ("Kinkos", etc.) use case, the output devices on the service (Cloud Print Manager) end will likely not be exposed to the Cloud Print Service or Client.
>>> I think if we go down the route of aggregating multiple physical printers behind a single print manager, but we only advertise a single device, we're going to run into a lot of problems (and existing solutions) that are meant to operate from a client to the actual printing device.
>> Given that this has been a feature of IPP for 14 years and a feature of protocols/solutions for many years prior to that, I don't think this will be the case.
>>> In the meeting we talked about advertising capabilities for a 1-to-many print manager -- according to the minutes, the capabilities can be a union or an intersection. This seems ambiguous to the client, and could be a threat to expected results and print fidelity.
>> It is up to the Cloud Print Manager to route the jobs as needed to the corresponding output device(s).
>>> At the moment, this is an intuitive judgment, based on a recent conversation with a colleague regarding what the "intersection" of capabilities means to a client. It's possible that one physical printer could be served by two different print managers, where one advertises an intersection, the other a union.
>> This would be an implementation choice based on the capabilities of the Cloud Print Manager. Some implementations might report the intersection in order to provide high-availability printing (this is the approach utilized by CUPS), others might report the union and route jobs to printers with the corresponding capabilities (this would be the approach utilized by print services).
>>> I think someone needs to create a workflow diagram, utilizing the printing user interface of a popular platform (Windows, Mac, other) to show how each of the PWG semantic model printing operations would work in a print manager 1-to-many mapping, where the print manager "hides" multiple physical printers.
>> From the client perspective it will look and work the same.
>>> Or, document a 1-to-many print manager scenario that describes unambiguously what the expected results would be for each PWG Semantic Model Print operation, including any administrative functions.
>> Administrative functions control the Cloud Print Service, and indirectly the Cloud Print Manager which gets notified when jobs should be stopped, etc. Clearly we need to document and model how state and configuration changes to the Cloud Print Service are reflected in the Cloud Print Manager, but since all of the administrative operations are service-centric that should not pose a problem. I don't see a specific need to separately document the 1-to-1 and 1-to-many configurations, other than perhaps a footnote referencing IPP fan-out and output devices.
>> The only access to device control is indirectly through the power modes, but there you aren't saying "turn yourself off" but rather "if you are inactive for more than 2 hours, go into low power mode". All of that is optional, not widely implemented anyways, and could be replicated to multiple output devices by the Cloud Print Manager...
> 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.