- From: Roy T. Fielding <fielding@kiwi.ics.uci.edu>
- Date: Sat, 23 Jan 1999 22:45:03 -0800
- To: Nick Webb <nwebb@auco.com>
- Cc: ipp@pwg.org, http-wg@cuckoo.hpl.hp.com
>>An IPP server is not going to be a general-purpose HTTP server, >>and implementing it as a CGI script would be braindead anyway, > >That sounds like a very considered opinion, can you elucidate? > >For the record, we've implemented IPP as CGI (well, a set of C++ functions >called by our general purpose embedded web server) and all seems to be That is not CGI, nor is an embedded web server general-purpose. Any server where you have control over the nature of the resources back-end is not general-purpose. The reason it doesn't make any sense to implement IPP via a CGI script is because the server is being installed specifically to listen to IPP requests on the IPP port, and thus doesn't need to deal with the multifaceted heterogenerity of resources on a general-purpose HTTP server. It therefore doesn't make sense to have an IPP implementation that is generic among many servers (the ONLY reason to ever use CGI). >running fine. I can think of many reasons why you'd want to base it on an >existing web server, not the least of which is keeping the code size >reasonable. I would imagine that most printer OEMs would do a lot of soul >searching before deciding to use two separate instances of much the same >code in a printer... Your own implementation uses a server-specific API on a specific set of pre-allocated printer resources within an embedded system. That is exactly what I would expect of an IPP implementation, and there is no reason why you can't support chunked requests. My point was that it is silly to limit IPP capabilities to the lowest common denominator of existing HTTP origin servers, since IPP isn't an existing HTTP service. ....Roy
Received on Saturday, 23 January 1999 22:54:32 UTC