"IF you wanted to use HTTP, how would you do it?"
Clearly, there are many advantages to starting with a clean RPC
instead of HTTP if all that counts is single protocol simplicity.
Why not elaborate the options a little better before continuing with
what otherwise promises to be an endless debate without much
resolution?
- What does printing with RPC look like?
- What does printing with HTTP look like?
What's common? How do they differ?
I think there are many more important things to get done than just the
transport: what's in a job description, how does one describe printer
capabilities, etc.
# In HTTP, is is possible for the client to send a job, the printer bogs down
# in printing it, it never responds, and the client times out or the HTTP
# server stack times out waiting for the CGI script to finish, and then
# resends the job and the job is printed twice?
Most RPCs don't have transactions either. It would be a bad idea for
HTTP-based printing to wait before returning from the POST that
submits a print job. I'd suggest
a) HTTP POST to submit the job, return a URL for job status
b) client polls job status URL to get state
This doesn't require connections or clients to stay alive. The job URL
should be unique. Having an active job have a unique URL has a lot of
advantages, e.g., 'cancel' can be an operation on the job URL, and it
scales nicely into print redirectors.
If you want to avoid duplicate print jobs, have HTTP post return a job
URL and require another "go ahead" operation to actually start
the job print. If the initial post fails, you don't get the
job URL. If you get the job URL and don't get an ack from the "go
ahead", you can try ack-ing again.
I think this works independent of whether you're using HTTP or some
other kind of RPC, but it maps nicely into the "URLs locate resource"
model of the web.
It may be that WEBDAV will require HTTP transactions anyway, though.
# It seems like caching and proxies is only an issue on GETs.
Actually, no. Other requests can be cached too. It's only if you leave
out cache control headers entirely that the method matters.
# As was pointed out in the BOF, most of the IPP operations will
# probably be MIME encoded requests in a PUT with the response coming
# back in the response to the PUT.
PUT is almost never appropriate for printing; try "POST" instead.
# However, I agree with Keith, that all of the work being done for
# HTTP/1.1 and beyond is NOT taking the needs of printing into account!
This is true about the past, but there's actually not much left for
HTTP/1.1 except for clarifications, fixing bugs, and a few odds and
ends, some of which seem also relevant to printing:
a) content and feature set negotiation
(although printing and fax need the converse)
b) versioning & distributed authoring
(transactions? updates?)
c) protocol extensions (PEP)
Regards,
Larry