From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <3DF0E854.3050802@easysw.com> Date: Fri, 06 Dec 2002 13:11:32 -0500 From: Michael Sweet MIME-Version: 1.0 Subject: Re: [Printing-architecture] Bi-di plug-in functionarities References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: printing-architecture-admin@freestandards.org Errors-To: printing-architecture-admin@freestandards.org List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: To: Pete Zannucci Cc: printing-architecture@freestandards.org Pete Zannucci wrote: > Michael Sweet wrote: > > >>FWIW, in CUPS #3 is normally handled by the backend (in CUPS 1.1 >>and earlier) and/or by the driver (in CUPS 1.2), the idea being >>that the same commands/protocols will generally be used over >>serial, parallel, USB, and network connections, and since the >>driver has a copy of the device URI (the device for the printer) >>it can tailor its input/output accordingly. > > > With using backends, how do we handle spool information that may > be needed to do recovery, restart a job, rerender a page, and possibly > manage other asynchronous events that may need to be mananged? The backend would have to understand the PDL, which is one of the reasons we've added backchannel support in CUPS 1.2 so that the driver (which is generating the PDL) can handle these details. > I realize there may be potential security issues but in my diagrams > I attempted to allow for management of the spool system and rendering > along with async. data manipulation. Is there any easy way with CUPS > to provide similar function so that we don't end up with issues such > as jobs disappearing along with providing robust recovery from errors? There isn't any reason that you couldn't create a backend that communicated with a common interface/daemon/server to provide concurrent access to a device; the HP OfficeJet drivers do this IIRC... The main issue is that print data is generated by the filters for the whole job as a stream, so drivers/backends need to save the whole print file if they want to support recovery. Also, you may need to add a common set of initialization commands to the front of any recovery data to get the printer into the right mode(s). What we're concentrating on for CUPS 1.2 is better error tracking, page accounting, and event notification which will allow for more robust drivers to be written. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com