Wie ich in meinem letzten Beitrag bereits andeutete funktionieren Clouddruckdienste aber in der Regel mit mindestens einem "Mittelsmann": Der Drucker P meldet sich bei Server S des Diensteanbieters an und ein beliebiger anderer Rechner C im Internet kann S kontaktieren um Dokumente in eine Warteschlange für P einzustellen. Die Kommunikation zwischen C und S erfolgt dabei oft per HTTP oder E-Mail. Der Drucker ist also gerade nicht direkt an den Rechner angeschlossen, der das Dokument produziert, sondern ein öffentlicher Server fungiert als Druckerserver. Wenn P nicht selbst das Cloudprotokoll unterstützt braucht man oft noch einen weiteren Rechner als Proxy, der eine direkte Verbindung zu P sowie eine Netzwerkverbindung zu S hat und als Protokolladapter zwischen P und S fungiert.

Ob die Nutzung eines Clouddruckdienstes für Gustl von Vorteil sein könnte, hängt von der Netzwerktopologie der geplanten Anwendung ab. Man muss den Drucker nur irgendwie vom Server oder Browser aus kontrollieren können, um Daten direkt zu drucken. Ob man da jetzt per XMLHttpRequest Daten an einen IPP-Server schickt, per HTTP oder WebSocket einen lokalen Proxy anspricht, vom Server aus per LPR spoolt oder einen Clouddienst anspricht ist im Endeffekt Jacke wie Hose, aber was praktisch gut umzusetzen ist, hängt von der Netzwerkumgebung ab.