Opened 14 years ago
Closed 14 years ago
#13 closed enhancement (invalid)
Create an API for accessing the queue information
Reported by: | jhamrick | Owned by: | jhamrick |
---|---|---|---|
Priority: | blocker | Component: | server |
Keywords: | Cc: |
Description
As we add more features to Gutenbach, there are many things that need to be able to access the queue data -- client scripts, the gutenbach-queue package, and the web interface. It is better if this information is stored in a database somewhere, and is updated periodically, instead of polling CUPS every single time.
Change History (3)
comment:1 Changed 14 years ago by quentin
comment:2 Changed 14 years ago by jhamrick
CUPS is relatively quick when using the perl bindings, but the problem is more that there might be tons of clients polling all the time as opposed to CUPS being slow. For example, I imagine that the web interface will poll once every few seconds -- add ten clients and even if CUPS is fast, the server will be swamped.
How do you suggest caching the queue? I feel like a small database makes it very easy and fast to both query and manage.
comment:3 Changed 14 years ago by jhamrick
- Resolution set to invalid
- Status changed from new to closed
After discussing with broglek and quentin, we have come to the conclusion that writing our own IPP server will likely resolve all our problems. We only actually use the queue functionality of CUPS, and none of it's shiny features, so we're using only a small part of this giant piece of software, and it doesn't even work the way we want it to all the time. So, it's probably better to just reimplement that small piece of CUPS. That way, when bugs crop up, we can fix them ourselves instead of looking for a way around it in CUPS. This also automatically fixes the API problem, as we can just send IPP requests to our server (i.e., it includes the API functionality already). In addition, all CUPS commands should still work with our server, as they ultimately just send IPP requests.
I'm not convinced this is a good idea - CUPS is the authoritative source for queue data. I think what's actually driving this ticket is that CUPS can be slow at delivering the queue. We should first investigate that to see if there's something we can fix.
Beyond that, I think the right architecture would be to have a simple daemon that caches the queue for n seconds. This doesn't seem like it belongs in a database.