On Wed, 2005-07-20 at 09:41 -0600, Andreas J. Guelzow wrote: > I disagree. The import of some of the eggcups into libgnomecups (You mean libgnomecups, but yeah). > 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. 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. Why wouldn't one have a local cupsd? > 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?
Attachment:
signature.asc
Description: This is a digitally signed message part