Use a minimal HTTP/1.1 implementation.
Now I'll have to prove this, right? I think a minimal HTTP/1.1 server
can be implemented very simply; despite all of the MUST's in HTTP/1.1,
most of the additional "MUST" requirements are on proxies and not on
clients or servers, and even then, you can avoid most of the burden by
judicious use of cache-control headers.
I think there were too many 'MUST's in HTTP/1.1 proposed standard, and
I hope we can drop the unnecessary ones.
# I hate to burden an embedded system with lots of protocol baggage
# that's not needed.
I hate to burden HTTP with a lot of protocol baggage that's not needed
by those applications that don't need them.
# 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'm not willing to assume that we're stuck with features of HTTP that
aren't needed.
# 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.
Name two examples of cruft (ok, Host: and cache-control:), but name
two more examples of cruft.
# > 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.
Waiting? I was just suggesting that something that Internet printing
might not need right now (unless you're printing checks at remote
locations) was "along the path of development" of HTTP.
Besides, WEBDAV thinks they'll be done in 3 months ;)
Larry