Fetch jobs from cloud queue

[tresf]

Some form of cloud-queuing feature has been requested. I'm hesitant to get into the cloud-service offering because it requires a near-100% service reliability of our servers that is very hard to maintain on scale.

However, each QZ Tray instance could be configured to monitor a cloud queue of the client's choosing via a configuration. This way the queue could be fetched and processed in a FIFO manner.

Since QZ Tray would be blind of the details, I believe we'd need:

• PC Name (or a wildcard for all)
• Printer Name (or the "default printer" if not provided)
• Any other filters?

I would like QZ Tray to continue normal operation in tandem.

We will need to determine the following:

• What format is the data in? JSON? How does QZ Tray get notified of changes to this data?
• What authentication techniques do we offer? How do we store this securely?
• What UIs will be available for configuring this? How can we also offer these in headless mode?
• What UIs will be available for monitoring this? How can we also offer these in headless mode?
• How will QZ Tray inform that is currently processing a job? How will other QZ Tray instances know that the job was processed elsewhere so that it is not duplicated?

[gehres]

My thoughts on this are as follows:

The server would be provided by your customer, not by you (simple web socket server), and the QZ-Tray would remain installed on the customer's PC, but would now be connected to the web socket server provided by your customer rather than the browser tab.

The QZ-Tray would just be a web socket client providing the same printer and hardware information and actions as it actually does now, through the internet.

It simply eliminates the need for a browser-tab connection and provides a direct connection to the server.Everything I do through the browser would be possible through the server.

Why:

a) With that, your customer can provide the server redundancy to have the reliability he needs.

b) Because the Web Socket protocol has its own authentication, you could add IP addresses to the end of each side to improve security.

 c) Your customer could contract a WebSocket service to handle that (Pusher.com, crossbar.io, websocket.org, etc).

d) You don't need to implement a queue on the client or server side if the QZ can provide printer queue information via a function like printers ().We might be able to find a job () for a printer.

 c) You can track the web socket connection and give feedback to the client when it disconnects.

This way, we don't need to change the QZ-Tray function (perhaps by providing a job list for each printer), but instead simply provide a way for it to connect directly to the server rather than to the browser tab.

Please accept my apologies if I didn't understand.

[KevinOBrienCimpress]

Hi! I was curious to see if any progress or planning has been made on this issue as we would definitely be interested in it. Thanks!

[tresf]

Hi! I was curious to see if any progress or planning has been made on this issue as we would definitely be interested in it. Thanks!

Hi,

No, not yet. Progress on this feature has not yet been started. Clients requiring such a feature are currently writing their own watchdog services. We will update this issue once development begins. At time of writing this, there is no strict timeline for this feature.

[KevinOBrienCimpress]

Thanks for the update @tresf. I'd be interested in learning more about the watchdog services. Is there any additional information you might be able to provide?

[tresf]

@KevinOBrienCimpress a watchdog service would generally be a custom solution to periodically check a cloud location for documents (using a proprietary technique) and then leveraging the QZ Tray API to print these.

For example, this solution could be written in Node.js to check a cloud location at an interval and then leverage QZ Tray's API for printing these documents.

We do not have a ready example for this, as the solutions tend to be proprietary in nature. We may be able to prepare a boilerplate watchdog, but this time may also be better spent implementing the feature into Java instead.