Re: eggcups (and libgnomecups) for 2.12

On Wed, 2005-20-07 at 12:06 -0400, Colin Walters wrote:
> > is now
> > apparently expecting that the cups client talks directly with the cups
> > daemon that is in charge of the printer(s). 
> Right.
> > As a consequence, a
> > configuration with local cupsd daemons that pick up available printers
> > via broadcast (and is therefore immune to long timeout delays) is only
> > supported through a code change and recompilation of libgnomecups,
> > specifically:
> Well, but the local cupsd only picks up available printer broadcasts; it
> doesn't monitor jobs.
> > diff -u -r1.31 gnome-cups-printer.c
> > --- libgnomecups/gnome-cups-printer.c   28 Mar 2005 15:48:35 -0000
> > 1.31
> > +++ libgnomecups/gnome-cups-printer.c   20 Jul 2005 15:33:23 -0000
> > @@ -282,7 +282,7 @@
> >   * that will produce an infinite loop when presented with an invalid
> >   * hostname.  This will also produce a hang if the remote printer is
> >   * unavailable and we do a syncronous lookup. */
> > -static gboolean go_directly_to_printer_when_possible = FALSE;
> > +static gboolean go_directly_to_printer_when_possible = TRUE;
> >
> > (Note that the comment in the above code talks about the "hang" which
> > only happens without local cupsd daemons.)
> Yes, I don't think we had considered the possibility of not having a
> local cupsd. 

I don't understand? We have a local cupsd daemon.  

>  We did some work to make most operations like retrieving
> printer status (from remote printers) asynchronous, but certainly some
> things are synchronous simply because we knew they were talking to the
> local cupsd and thus should be reliable.  I don't think it would be
> impossible to make those operations asynchronous, but also think it
> would be far from trivial.

Everything worked fine for us before these changes of making things

> Why wouldn't one have a local cupsd?

Good question. We have local cups daemons. Since the whole asynchronous
stuff apparently got included to avoid delays when talking with a
non-responsive remote cups daemon, I assume there are some people
somewhere that are trying to avoid having a local cups daemon.

> > So the "important end user visible functionality" in act makes this
> > library useless to many users.
> Users who don't have a local cupsd?  Do I understand the scope of the
> issue here correctly?

No. Users who _do_have_ local daemons that talk with several remote
daemons that administer the printers. Remember in this configuration,
the ppd files reside with the remote cups daemon. the whole pont of
broadcasting printers is that we do not have to configure those printers
on each client. The local cupsd daemons just pick up the printers from
the broadcasts.

Andreas J. Guelzow
Taliesin Software, Shelties, Pyr Sheps
and Shetland Sheep

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]