From owner-freebsd-current Thu Dec 4 12:18:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA24769 for current-outgoing; Thu, 4 Dec 1997 12:18:00 -0800 (PST) (envelope-from owner-freebsd-current) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA24749 for ; Thu, 4 Dec 1997 12:17:54 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id GAA10446; Thu, 4 Dec 1997 06:45:17 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp01.primenet.com, id smtpd010430; Thu Dec 4 06:45:13 1997 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id NAA13215; Thu, 4 Dec 1997 13:17:16 -0700 (MST) From: Terry Lambert Message-Id: <199712042017.NAA13215@usr09.primenet.com> Subject: Re: Changing lpd's model of operation slightly... To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Thu, 4 Dec 1997 20:17:16 +0000 (GMT) Cc: wollman@khavrinen.lcs.mit.edu, current@FreeBSD.ORG In-Reply-To: <7580.881226978@critter.freebsd.dk> from "Poul-Henning Kamp" at Dec 4, 97 10:16:18 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >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" :-) The problem with the POSIX printing model (which is what your suggestion hints at exploding into ;-)) is that it doesn't have a generic queueing system that it's layered on top of... I think that use of a generic queueing system should probably wait until one is written. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.