> >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? :-) >