Ответ: ?????: LPD applet

[Vladimir Dronnikov]

1. What you mean for "configurable" when you mention the small room
for data on the system? A spool MUST dump a job before the latter gets
started. Or it is NOT a spool. Did you mean for "configurable" turning
spooling off?

2. Please explain what all these "header pages" are?

3. popen(WHAT) has to be configurable to be flexible. Configurable
here means bloaty. Those who have got a shell would IMHO prefer named
scripts.

Nevertheless, I got stuck at the following question:

A. Do we REALLY need to expect from LPD applet any functionality
beyond implementing "Receive Job" command (both non- and spooling
flavors)? I mean all these queue states, job removes and so on.

--
Vladimir


2008/2/25, walter harms <WHarms at bfs.de>:
>
>
> Vladimir Dronnikov wrote:
> > Hi, Walter!
> >
> > 1. Let us discuss spool format.
> > 2. Let us decide whether to support all these banner pages, mailing
> > features, ...
> > 3. Let us decide whether to delegate "actual" printing to a helper
> > application or just dump data file to a device or a file.
> >
> > My draft proposal is:
> > 1. Spool can be similar to Maildir: incoming jobs are dumped to tmp,
> > then are moved atomically to new. A special thread (or process) then
> > spawned which moves pending job from new to cur and prerforms "actual"
> > printing.
>
> no problem with that as long it is configurable. E.g. our system has
> 64mb for everything (most is eaten by data) but is capable of using a
> usb-stick. For a few euros you get gigabytes.
> I have no idea why you want a thread. the mail analogy is fine. you need
> one "dispatcher" and a "deliverer" for each queue. and you are ready.
>
> The "deliverer" can make all the filtering popen(" cat myfile | myfilter -o
> myoptions | cat >mydevice");
> an interesting question is "can we/you explore similarities from the
> mailsystem"
> (we have a sendmail and i never took a look into it)
>
>
> the tricky job is to implement priority, changes of etc. we can drop it.
>
>
> >
> > 2. Not for now. Printing to laser printers differs dramatically from
> > printing to line printers. To make LPD smart enough to produce pages
> > by itself is
> > IMHO just a bloat for now.
> >
> do not think to much about it, when we do not need a backchannel it is easy.
> lpd should not produce pages other than the header page.
>
> > 3. Helpers rule: we can have pre, print, post scripts that can perform
> > all smart capabilities (banners, mail notification,  etc.) of #2. If a
> > print script is absent we can just dump datafile to the device. Yes,
> > this may be way tricky but the power and flexibility of such an
> > approach deserves tricks inventions :)
> >
>
>
> mail is simple and can be done via popen(). it is the only way the system
> can
> inform the user about an aborted job.
>
>
> re,
>  wh
>
>
> > --
> > Vladimir
> >
> >
> > 2008/2/25, walter harms <WHarms at bfs.de>:
> >>
> >> dronnikov at gmail.com wrote:
> >>> Hi!
> >>>
> >>> Cosmetic changes to lpr.
> >>>
> >>> New applet: tiny lpd. Seems to be working with lp[rq] applets :)
> >>> Needs to be tested on real printing device and I do not have any...
> >>>
> >>> Need feedback, people!
> >>> Do we want any queueing?
> >>> Do we need some pre- and postprocessing, preferably via external
> helpers?
> >>>
> >>> --
> >>> Vladimir
> >>>
> >> Hi Vladimir,
> >> just give me some more time.
> >>
> >> an because you ask: i would like to see some spooling daemon.
> >> 1. there are non-spooling lpd daemons out there.
> >> 2. spooling is a good solution for bad lines to prevent data loss
> >>
> >> btw: you do not need a printing device any decent ld lets you print to a
> >> file
> >> please be aware that implementing filter can be tricky.
> >>
> >>
> >>
> >> re,
> >>  wh
> >>
> >
> >
> >
>