On Thu, Nov 26, 2009 at 4:42 AM, Wim Dumon <[email protected]> wrote: > > Hello Craig, > > 2009/11/26 Craig Miller <[email protected]>: > > I've poked around the website, forum, wiki, and searched the list archives > > but only found one reference to an ISAPI Connector. Has anyone considered > > the details of implementing this in more detail? > > > > I'd like to run a Wt app under IIS and an ISAPI extension based Wt connector > > would make this really clean. > > > > I have looked to ISAPI (not too much in detail, though), and I'm > curious as to how you consider this cleaner than to configure reverse > proxy to a separately deployed Wt application. > > We would have to decide on the process model: Run in the IIS process? > run the application in a separate process and only the connector in > the IIS process? > > The first model is probably simpler to develop, but if your > application crashes it takes the entire IIS down. Also, I would need > to verify that IIS indeed uses only one process (with multiple > threads) to handle all requests, so that all requests for a particular > session always end up in the same address space. > > In the second case, an ISAPI dll should basically forward all requests > to a Wt application that runs in a separate process, and therefore it > would be quite equivalent to a reverse proxy (we might decide on using > a different protocol than http, like in our fcgi backend where we use > fcgi). For fcgi, we implemented this model (apache spawns multiple > processes and it's not possible to force all requests for the same > session always to the same process) . > > What could be the advantages of developing a ISAPI connector? > - the isapi connector could start the wt application if it's not yet > running, and restart it if it would crash > - isapi seems to support asynchronous io for responses. we could take > advantage of this, especially for server push > - maybe easier to configure in iis? I have no experience with this, > but the connector would still have to be informed for which Wt > application it is the connector (maybe an extra config file?) > - probably makes deployment of wt applications on wt easier > > At first sight, adding an ISAPI connector should not be too much work. > We'd do it if it's worth the effort, but it seems to me that there is > only limited interest in it. On the other hand, the benefits may be > worth the effort. > > > Best regards, > Wim Dumon.
Hi Wim, Thanks for the thoughtful reply. By "Cleaner" I only meant that all the web-apps on a particular computer are deployed on top of the same web server. Allowing the security, App pooling policy, etc to be controlled in one central place, no additional ports opened in the firewall, etc. On its face, it seems less complicated (cleaner) to deploy a single ISAPI plugin for each Wt based application I create, but I'm not asserting a strong opinion here. I'm very new to both ISAPI and Wt and am just interested in keeping the deployments simplified (less pieces). Implementation-wise, it may be much more complicated to deploy Wt apps w/ an ISAPI connector. It sounds like I need to look more closely at the role of Wt connectors before forming my opinion. I'll read the rest of your email with great interest on Monday when I return from holiday. Regards, Craig ------------------------------------------------------------------------------ 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
