I share everyone else's desire to use a "stock" HTTP server when
implementing IPP. The reasons are clear, as you mentioned (i.e. the use
of stock internet/intarnet tools available cheaply).
Just note that even when using such an "stock" HTTP server (be it a CGI
or ISAPI standard) you still need to develop a CGI application or an
ISAPI dll that implements the IPP on the server. So there would still be
a need for a server-side plug-in or add-on, on top of whatever "stock"
HTTP server we are using.
Babak
>
>We have always realized that the IPP could propose a new URI "scheme"
>(eg, "ipp://") to effect job protocol interactions, but this would require
>changes to stock server implementations. Hence, this approach was not
>favored.
>
>While it has never been stated in quite this fashion, the strong disposition
>toward using HTTP stems from the desire to use a stock HTTP server as a sort
>of "object invocation" vehicle; that is, be able to use CGI-like program
>invocations to respond to protocol requests. (In this case, the HTTP server
>acts as an extremely lean-n-mean ORB mechanism...well, sort of, anyway ;-)
>