Randy,
I have implemented numerous print/mfd solutions with this type
configuration.
Examples included:
A single incoming print feed, with copies distributed to many printers.
An incoming print feed modified to add overlay or other security measures
(authentication, release codes).
Redirection of output to another printer/location, without requiring sender
to change.
Provided an additional network segment to traverse, reducing exposure to
internal/external attacks (in both directions).
In a number of these examples, the sender of the print data and the consumer
of the data were separate entities.
Larry Upthegrove
-----Original Message-----
From: cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org] On Behalf Of
Randy Turner
Sent: Thursday, December 20, 2012 8:23 AM
To: cloud at pwg.org
Subject: Re: [Cloud] print manager design
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.
R.
On Dec 20, 2012, at 7:23 AM, Michael Sweet <msweet at apple.com> wrote:
> Randy,
>> 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.
_______________________________________________
cloud mailing list
cloud at pwg.orghttps://www.pwg.org/mailman/listinfo/cloud
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.