The printer system is designed to operate without a central server, and without a single source of printer content. It achieves this by using printer URLs to identify and send content to printers.
First, some terminology:
POSTs) the URLs of pages that contain content to be printed
Here's how it all basically fits together:
In its simplest form, there is a single printer, connected to a single backend server, with a single content provider:
The printer polls the backend server at regular intervals, checking for content to be printed. If there is none, the backend simply sends an empty response (
Content-length: 0), which the printer will then ignore. The URL that the printer polls is composed of the base URL of the backend server (
http://backend1) and the printer's unique ID (
abc123 in this case) --
At any point, a content service can post to the printer's print URL, which is also composed of the backend server's URL and the printer's ID --
When a content service sends a request also contains a
url parameter, which points at the content which should ultimately be printed. In this case, the full
url parameter is
http://content/789xyz. This URL should contain as much information as the content service requires to properly determine the content for that printer. For example, it could also contain the printer ID, or a user ID, or any other parameters that might be necessary.
(Normally, this URL will be served by the content service itself, although that's not strictly necessary; what's important is that the URL is accessible to the backend server.)
The backend server then asynchronously makes a request for that URL, and once it receives a response, the backend is responsible for rasterising it.
When this process is completed, the next time the printer polls the backend server, the response will not be empty -- it will contain the printer data which the printer can finally print.
Because the printers have unique IDs, more than one printer can be maintained by a single backend server. As long as the content service knows the unique printer URLs for each printer, it can reliably send specific content to each printer individually.
In this example, the content service sends the content at
http://content-a/789xyz to printer
abc123, and then sends the content at
http://content-a/715jkl to printer
bcd234. The backend server is responsible for offering the correct content up to each printer, based on the URL that they are polling.
Naturally, many completely unrelated content services can send data to a single printer.
In this example, there are two content services, at
http://content-b respectively. If they both know the URL of the same printer (
http://backend1/print/abc123), then they can both send content to it.
The backend server doesn't really care that the two content requests are coming from different services; because the
url parameter sent also includes the host, those URLs could be served from any host, on any network that is accessible to the backend server.
To really demonstrate the distributed, federated nature of this architecture, consider the example below, where there are multiple printers and multiple backend servers.
The content service has been informed about two printers:
In a similar way to the service-agnostic backend server described above, the content service is also backend-agnostic. Each printer URL includes a fully-qualified host, and when the content service is sending its
POST request, it does not have to care which backend server is ultimately servicing requests to that printer URL.