More on print services

My post about print services appears to have caused some confusion. While I prefer to get feedback in the form of comments, so others can also comment and a dialogue is established, here are some clarifications — at the risk of making things even muddier.

The first confusion is when the same word is used for something different, a subtle polysemy problem. What we call now the Internet, was called the ARPAnet thirty years ago. At that time Xerox had Ethernet local area networks (LAN) at its sites, and they were interconnected through gateways to create the Xerox Internet. This Internet was a node on the ARPAnet and used the same naming scheme, so it was seamlessly integrated. For example, you could write my email address as beretta.pa@xerox.com or as beretta@pa.xerox.com.

PARC was also connected to other networks, like the DecNet, but is was not seamlessly integrated and your email address had to finish in !ucb!parc|beretta to find its way to a gateway from which I could access it.

Thirty years ago was before the general availability of workstations, so the ARPAnet did not have many nodes. However, the Xerox Internet had thousands and workstations. Therefore, the researchers at PARC had to solve all the scalability issues before anybody else was even aware of them.

While the Internet connects logical machines, the World Wide Web hyperlinks documents, using a protocol called HTTP. Initially the Web was mostly text-based, but then its inventor at CERN found out how easy it was to implement a graphical browser on the NeXT system, and the rest is history.

Next, RPC did not disappear, but it was constantly metamorphing. Here is a diagram of the protocol evolution for services Rob Buckley drew several years ago. It stops at 2000, and now there is a number of web service frameworks, a list of which you can find on the Wikipedia.

A popular way to represent Web service architectures is using the so-called three-tier architecture concepts.

Two popular models are Microsoft's .net and Sun Microsystem's J2EE.

The jargon on the right hand side can be decoded with this J2 acronym list.

Finally, print services are not used just for printing but also for proofing. The latter is somewhat delicate, because the print provider needs to maintain control of the proofing device and the viewing conditions. One approach is to use a remote sensor to assess the ambient conditions and then apply a color appearance model (USP 6,078,732 etc.). Another approach is to use an electronic color proof (ECP) node that mediates the sharing of information about the capabilities of nodal color devices, the interpretation of color image data to the devices, and the control of color reproduction (USP 6,157,735 etc.).