[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