From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] The new ridiculous license From: Geoff Collyer In-Reply-To: <20030620115233.3dc850df.ggm@apnic.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Thu, 19 Jun 2003 19:32:57 -0700 Topicbox-Message-UUID: d2054cee-eacb-11e9-9e20-41e7f4b1d025 Printer spoolers once had a purpose, when printers really were *line* printers; that is, they were dumb devices that printed a line of text at a time, using a rotating drum or chain and hammers that beat paper against the drum or chain. This is the model behind V7's lp(4) for the DEC LP-11. Many young people have probably never seen one of these in person, except perhaps in a computer museum. Once printers became stand-alone devices on a network, they should have become a lot smarter. They had TCP/IP and PostScript interpreters inside them, after all, so they had to have some smarts. I think Imagen more-or-less got this right but virtually no one since has. A printer should be able to take a very large number of concurrent connections and spool the PostScript files sent internally. Especially nowadays, with the costs of the hardware components so low, a printer ought to have a studly processor, a big bag of memory and the usual obscenely-large disk, and some of the high-end printers do. As far as I know, though, even the best of these can take at most 0001 simultaneous inbound connections. As a client, I ought to be able to open a connection to a printer (and almost never have the connection attempt fail), throw Postscript at the printer, close the connection, and be able to count on the printer to print that file, *eventually*, come power outage, paper jam, or running out of paper or toner. (Sending cutesy messages saying roughly `the paper jammed, and you didn't notice within 4 minutes, so I threw your job away; have a nice day' is not acceptable.) Given such printers, one doesn't need a print spooler at all (or rather, the print spooler moves into the printer, where it's invisible). In the absence of such printers, one could put a Plan 9 CPU server in front of one or more printers, but present a file system interface instead of lp or port 515. Clients could then import the spool directory and add, remove or list jobs. The printer would be able to authenticate the client and thus apply suitable restrictions on what can be removed, for example. Copying a Postscript file into the spool directory should be sufficient to queue it.