[Desktop_printing] CUPS code quality ...

John (J5) Palmieri johnp at redhat.com
Thu Feb 2 10:53:56 PST 2006


On Thu, 2006-02-02 at 08:35 -0500, Michael Sweet wrote:
> michael meeks wrote:
> You *do* know that you can do a CUPS_GET_PRINTERS request with a
> non-blocking HTTP connection to collect the data as you go along,
> right?  And use requested-attributes to reduce the amount of data
> that is processed?

I just did this using a g_source to preform non-blocking requests.  I
should be checking it into the print-operations module in libegg soon.
The biggest problem I ran into was lack of documentation.  The
documentation is great for the convenience functions but the only method
that mentioned non-bocking operations was the httpBlocking API which did
not give any pitfalls to using it.  It would have been nice for there to
be a note stating they do not work with the convenience functions.  Even
better would be for the convenience functions to yell loudly if you try
to use a non-blocking http connection with them.  After some fiddling
with the code I was able to figure out the order of calls I needed to
make to complete a non-blocking request.  

A better API model might be this:

blocking:
- convenience call to construct request
- send request blocking
- process response

non-blocking:
- convenience call to construct request
- send request non-blocking
- check request complete function run by app at key points
- if complete response received:
  - branch and process response

non-blocking with main loop:
- toolkit provided method which integrates request checking into
mainloop
- convenience call to construct request
- toolkit provided method for attaching callback to request
- send request non-blocking
- if complete response received:
  - dispatch response
- if timeout:
  - dispatch error

In this model blocking can just be thought of non-blocking with its own
loop that checks for a response.

This is an alternative that I came up with from my experience with
D-Bus.  D-Bus was made with desktop applications in mind and we have had
a lot of success with integrating this model in an environment that need
to make sure we don't block redraws and other GUI operations while
waiting for a response.

-- 
John (J5) Palmieri <johnp at redhat.com>




More information about the Printing-summit mailing list