kugler at us.ibm.com wrote:
> ...
> I claim that if you have an IPP server implementation, you've got
> most of what you need to make an IPP client. Accepting IPP
> ...
This may be the case for some implementations (it certainly is for
CUPS - the client and server share 99% of the HTTP and IPP
processing code)
However, the issue is not whether the IPP server can generate an
IPP request to send to another server. Moving a job to the new
server potentially requires:
1. Encryption
2. Authentication
3. Transferring multiple files for a job
4. Handling of attribute conflicts
5. Getting a response back to the client with the
new printer-uri, job-uri, and job-id before the
client times out
I'm sure my list isn't complete.
Authentication is a big problem - how do we "proxy authenticate"
a request?
The multiple file per job issue is another problem - if the
destination doesn't support Create-Job and Send-Document, how
do you map the move then?
The timeout issue is real - imagine transferring a 200MB
document to another printer that only supports Print-Job?
You'd have to wait until the document is sent to get the
new job-id and associated attributes - the client might
give up waiting on the response, and then reissue the
request, etc...
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com