Michael wrote:
>kugler@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)
>
That's the case in our implementations, too.
>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
>
Clients shouldn't time out. To quote the IPP Model: At job submission
time, a Printer object, especially a non-spooling Printer, MAY accept jobs
that it does not have enough space for. In such a situation, a Printer
object MAY stop reading data from a client for an indefinite period of
time. A client MUST be prepared for a write operation to block for an
indefinite period of time
Similarly, the client should be prepared for a Move-Job operation to block
for an indefinite period of time.
>I'm sure my list isn't complete.
>
>Authentication is a big problem - how do we "proxy authenticate"
>a request?
>
This is where the Get-Job/Print-Job approach could be useful. The client
sucks the Job back from the old Printer and then submits it to the new
Printer in the usual way.
>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?
>
I would simply fail the Move-Job request with
server-error-operation-not-supported.
>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...
>
Again, clients shouldn't time out. Non-idempotent requests shouldn't be
retried, at least without human intervention.
>--
>______________________________________________________________________
>Michael Sweet, Easy Software Products mike@easysw.com
>Printing Software for UNIX http://www.easysw.com
-Carl
This archive was generated by hypermail 2b29 : Tue Jul 11 2000 - 14:50:19 EDT