I think we were both trying to address that question.
We differ about how we go about answering it. For me, the questions are:
how do I use HTTP without buying into all of the complexity of an HTTP
implementation that's not needed for printing? and: What's the minimum
core portion of HTTP that's useful as a generalized RPC mechanism? I
hate to burden an embedded system with lots of protocol baggage that's
not needed.
The other difference is: I'm not willing to assume that the unneeded
features of HTTP won't cause problems... *especially* when people
threaten to use unmodified HTTP client libraries in their printer client
implementations.
> 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.
Absolutely. IMHO, this is where the real work lies. Solve these problems,
figure out the minimum command-set that does what's needed, figure out
how to avoid duplicated or lost print jobs in the event of race conditions,
client crashes, or server crashes... and any reasonable and simple rpc
protocol (that can handle large payloads) will work just fine.
> 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
Yep, I was about suggest something similar. And yes, you'll have to
do this regardless of what rpc mechanism you use, but it will work
with any reasonable rpc mechanism. I even think HTTP is a pretty
good rpc mechanism to start with, because it's used to dealing
with large payloads, and -- with 1.1's chunked transfer-encoding --
doesn't require you to know the exact length of a file before transmission.
But *only* if we take out most of the cruft first.
> It may be that WEBDAV will require HTTP transactions anyway, though.
Perhaps, but let's not burden the print group with having to wait
on another group's output. That can cause months or even years
of delay.
Keith