[Cloud] print manager design

[Cloud] print manager design

Randy Turner rturner at amalfisystems.com
Thu Dec 20 03:47:31 UTC 2012


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.

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.

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.

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.

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.

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.  

For you old guys, the Novell PServer/RPrinter protocol worked similar to this where printers would poll a PServer for available jobs and pull them down -- but in the Novell case, I don't remember ever seeing a PServer "hide" the existence of printing devices that it was hosting.

It seems like the more the printing view of the client differs from what is actually the topology, there is likely to be problems with the way existing platform printing systems are designed.  

Randy

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.




More information about the cloud mailing list