Re: Gtk+ print support - request for feedback

["John (J5) Palmieri" <johnp redhat com>]

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 <johnp redhat com>