Backend implementing a polling-queue

[arkascha]

Hello again, 
thought it might make sense to share the current planning state...

Christian Reiner wrote:
> I am looking for a backend that implements a polling strategy:
> - print jobs are queued as usual
> - no communication/push to a device is done/possible
> - the queue waits for a client to connect and retrieve print jobs
> Reason for this requirement is simply network topology.
> 
> Now I am certainly willing to implement such a backend, but before
> starting it makes sense to look at existing things. However digging google
> for things like "cups backend polling" obviously cannot lead to any
> meaningful result :-(
> 
> So my questions are:
> 1.) does something in the direction of what I requested above exist ?
> 2.) are there things that stand against such a scheme ?
> 3.) do you have suggestions about the right way to implement this ?

I compared a number of scenarios and currently there are three favorites. 
One that requires changes to the CUPS base components, a second one that is 
something like a side-path and a third that combines both. 

1.) extension of the ipp command collection to embed additional queries into 
the well known request structure: 
- OP  ::= { hold-job | moce-job | cancel-job | poll-job }
- OPD ::= { next | first | last | single }
The typical usage is to 'poll-job' the next job waiting in the (passive) 
polling-queue. The result is a ipp (http) reply holding a series of headers 
(job details) and the job's payload (document) as content. This advance is 
slim and offers a build-in network transparency. IN this case the backends 
are completely passive, they only accept a job (if at all) and do nothing 
but wait. 
The drawback is that it more or less requires to expose the whole CUPS 
interface network wide which might not be desired. 

2.) the backends accept a job and open a unix domain socket (fiole system) 
to write into. As soon as a client reads from the socket the job is 
"delivered" and marked as done internally as every other backend does. 
Now why unix domain socket, why not a tcp/ip socket, since I desire network 
access ? There might be more than one such polling backend, latest in that 
case we require something like a 'frontend' for network communication. 
Otherwise we get a collection of several ports being opened, all of the 
having to be configured in the firewall and so on. 
I prefer to have a frontend server that cares about network communication, 
say an apache fast-cgi setup that has a single (dynamic) rule per queue to 
connect the ipp (http) request from outside to the local socket. This way a 
mapping of URLs pointing to different queues but using a single port to 
several local sockets is implemented. 

3.) this frontend server might also be an additional component of the CUPS 
base suite, not sure if embedded in the Browse-Daemon or standalone. 

In the end we can define a static URI for each such polling queue: 
http://<printers.company.org>/printers/HP12345/job/54321
Note: this URI does NOT point to a part in the CUPS webfrontend but in a 
separate address space, since we do not want to expose the CUPS interface to 
where a polling client is based. 


Ok, any suggestions, questions, enhancements, ideas, cheats, critisism ??
arkascha