>>OK, so what you are saying then is:
>> - A specialized print client is required on the client side
> - A specialized print server is required on the server side
>>And why do you think again that using HTTP is such a great idea?
>>Because you are playing with words again. As I said before, this thing we
>call a "driver" is far easier to write when you have all the underlying
>functionailty available on your stock Internet-capable PC software. Ditto for
>the server.
>>Come on people, it should be totally obvious by now that the
>modifications necessary to "stock" software is just as much, if not
>more than writing the driver to use a socket directly PLUS you have to
>consider all the possible corner cases of what happens with special
>HTTP handling (like caches) and new versions of HTTP.
>>Not obvious at all! I know becasue I am writing one! Caching and new versins
>of HTTP are all taken care of by the lower level APIs we use.
>>I am not sure why Babak keeps arguing that implementing to a socket
>API is so much harder than some other, higher level API. If that's the
>case for the particular platform he is concerned about, then one must
>wonder about the platform he is using. Without diving into the "NT
>print servers are going to take over the World"-discussion, I do want
>to point out that at least one developer of printer drivers (Hi
>Angelo!) is perfectly happy to write to the socket layer since the
>much touted development tools simply are not available in that case.
>>The platform I am writing to provides both sockets interface, and a much
>higher level, more abstract, more friendly interface on top of HTTP (among
>others). Which one do you think I ended up using? :-)
>