On Sat, 2006-03-04 at 13:07 -0500, Michael Sweet wrote: > John (J5) Palmieri wrote: > > ... > > That would be great. I would say eggcupsutils.c should be looked at > > closely and perhaps can be reworked to become part of the CUPS library > > itself. It provides a generic async framework for POST and GET. > > We've had several requests for a general-purpose async request > interface in CUPS, which is somewhat puzzling to me because the > only things that *aren't* asynchronous are the convenience APIs.
Putting all the lowlevel API's together and hooking them up in the right order is not something developers want to do every time they write an application. Having a convenience API that is async or makes it easier to hook up to an async mechanism without having to worry about the details brings consistency and reduces error. As an applications developer I don't care what state the POST is in, I just what to know what printers I have. > The eggcupsutils stuff is just wrapping the CUPS APIs to manage the > whole request, including authentication, but it doesn't expose > enough to allow an event-driven (think select() or poll() on the FD) > application to "do the right thing" for truly asynchronous operation. It does. eggcupsutils is just the layer between a mainloop and the low level stuff. It provides the abstraction needed to integrate with a any mainloop without having to recreate the wheel for every mainloop. If you look at eggprintbackendcups I do just that and attach the fd of the http request to poll. I admit it needs a bit of cleanup but it works. > There are also still blocking issues WRT authentication and > connecting to the server, so ultimately if we *do* add anything to > CUPS it will need to address them, too. In the authentication case the request should go into a need authentication state, the application would then setup an authenticated connection and pass it to the request, starting the process again. That is all stuff I want to figure out after the basics are done. As for connections I don't see why we can't also figure out a way to wrap them in an async API. -- John (J5) Palmieri <[EMAIL PROTECTED]> _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list