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 asynchronous. > > 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 > -- Andreas J. Guelzow Taliesin Software, Shelties, Pyr Sheps and Shetland Sheep
Attachment:
signature.asc
Description: This is a digitally signed message part