Date: Thu, 04 Dec 1997 10:16:18 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: current@FreeBSD.ORG Subject: Re: Changing lpd's model of operation slightly... Message-ID: <7580.881226978@critter.freebsd.dk> In-Reply-To: Your message of "Wed, 03 Dec 1997 13:18:29 EST." <199712031818.NAA13289@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199712031818.NAA13289@khavrinen.lcs.mit.edu>, Garrett Wollman write s: >What I'm planning on doing (or rather, have done and am planning on >committing once it's tested) is to separate the actual job-printing >functionality out of lpd and into a separate program which lpd >execv()s as necessary to start a printer. This allows that part of >the program to not occupy any memory resources while it is not being >used, but does increase the memory used on machines that host active >printers. Question: will the interface between lpd and this program be an internal one, or a officially supported interface ? Will this be for instance where we will plug in ghostscript or a bidirectional communication postscript driver in the future ? I would be really neat if we simply changed it to have a generic queing frontend, to which you could submit files and processing directives, a queue manager which will take care of submitting one job at a time, in right priority/order and so on, and then configurable backends to do the job. That would allow the backend to du many other things than just printing. Can you say "job-queue" :-) -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7580.881226978>