Re: LPRng

[Charles Wilson <cwilson at ece dot gatech dot edu>]

> I would like to provide an LPRng package.  This brings up a couple of
> points.
>
> 1) What should be done about the lpr.exe provided by cygutils?
I'm willing to rename "my" lpr (it's actually Rick Rankin's) to 
something like "lpr-simple", but I don't think it should be removed 
entirely.  Rick's code is a very simple spooler that explicitly uses 
Windows calls to access the printer device; I think we should keep it 
around for those that don't want the bulk of lprng with its filters and 
inbuilt rasterizers etc.

Anyway, keep me in the loop on this, and when it comes time to 
upload/release lprng -- assuming it passes review on this list -- let's 
coordinate and make sure that lprng and the updated cygutils get 
uploaded in the right order, or simultaneously.

> 2) Should I make LPRng dependent upon ifhp?
don't know enough about lprng to answer this one.

> 3) LPRng really wants to have its own userid to run under.  Should I
> create one automatically (assuming that's even doable)?  There is
> really a whole raft of sticky problems under here, especially since
> the userid is compiled in.
Urk.  That's messy -- and won't even work on W9x.  I think you've got 
quite a bit of testing and QA to do with this package, to ensure 
"expected" behavior as (client|server) X (NT/2k/XP | W9x).

See the earlier discussion w.r.t. xinetd and how to "install" without 
"turning on", and providing a script the user can run to "turn on" the 
server.

> 4) Should I build in SSL support?  You can't really provide it as an
> add-on.
Probably.

> Actually, 2-4 only matter if people want to use LPRng as a server. 
> Truthfully, I'm not even sure that ifhp can handle the parallel port
> under cygwin.
I like the separate packages idea.

--Chuck