Hey Craig, 2009/11/27 Craig Miller <[email protected]>: > WIM> At first sight, adding an ISAPI connector should not be too much work. > WIM> We'd do it if it's worth the effort, but it seems to me that there is > WIM> only limited interest in it. On the other hand, the benefits may be > WIM> worth the effort. > > Oh... I should have also said that my original question wasn't > intended to pile more work on your plate. You're right, based on the > email archive alone there seems to be very little interest from the > IIS world in creating an ISAPI connector. My were original questions > were an initial attempt to determine how much work it might entail. I > was investigating to determine if this might be something I could > contribute. I'm quite new to Wt and ISAPI. I'm sure that your deep > understanding of Wt and the current connectors would enable you to > come up with a much better ISAPI connector design than what I'd kick > out on a first try.
I think the largest part of the challenge would be to understand the ISAPI possibilities and pick one that is best suited. As to Wt, the following parts are needed: - you need to provide an implementation for src/web/WebRequest.h you already have two examples: src/http/HTTPRequest.[hC] and src/fcgi/FCGIStream.C (FCGIRequest) - you need to provide an implementation for src/http/WebStream.h but ignoring socket notifiers, that could be mostly a no-op, see src/http/HTTPStream.[Ch] - when you have an incoming request, you need to wrap it into a WebRequest, and call WebController::handleRequest - you need to provide an implementation of WServer (which bootstraps the server) here you probably can copy alot from src/http/WServer.C; this is probably the most work since you need to communicate well with the ISS environment for startup and shutdown, finding configuration files, etc... That being said, I still think you need to evaluate what the added value will be over using IIS as a reverse proxy. In the reverse proxy scenario the following is equally true: - you still have only one open port in your firewall (IIS): the wthttpds will only be listening for connections from localhost, and this is usually (always?) not blocked by a firewall (e.g. firefox uses this internally too to communicate between threads) - you can start/stop your application independent of the web server - you can easily debug your application from within your development environment Regards, koen ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ witty-interest mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/witty-interest
