Hey Andreas, 2010/2/1 Andreas Mohr <[email protected]>: > Hello all, > > web 2.0 greenhorne here ;) > > I'm currently frantically searching for a way to decouple individual web > apps (usually *.wt) from my large C++ application, to achieve a > sufficiently fast development cycle (simply accessing the app URL > to visit the newly-built session) instead of having to reload my entire app > upon every web app modification.
With reload, you mean 'rebuild/relink' or 'restart' or something else ? > Current design is a runtime-loaded (i.e., external) wt server library > that my program then loads if available (and which then launches wthttp > in a pthread), thus I _could_ use an external FastCGI solution > in order to simply relaunch the Wt server part instead of my entire app, > but this would then require a fifo or socket channel for transfers > from the app, instead of a direct API protocol. Right!? It is not entirely clear to me now if you are using wthttp or wtfcgi ? > Thus I thought: since the Wt homepage can invoke external .wt apps (in the > examples/ section, e.g. hello.wt), I should get the same thing going. > This means that my initial server startup doesn't need any entry points > configured (addEntryPoint()), but when browsing to that .wt app path, > the new app should get executed. The Wt homepage is deployed as follows: - an apache which redirects certain URLs to httpd's. - the Wt homepage simply serves URLs for the examples which when followed target the example using one of these redirection rules. So, technically, the Wt homepage does not really invoke new Wt applications. > Instead, what I get is a nice "BIN file" download of the .wt file, > both with Firefox and links (also when trying the "immediate redirect()" trick > within createApplication()). > I guess that this is due to comments in src/Wt/WServer (and elsewhere) > that the standalone wthttp is single-instance currently, > thus it probably cannot re-spawn a new app and instead offers a download. Not really, unless the URL corresponds to a specific entry point, it will be treated as a plain file. I guess what you are looking for is some way to intercept a web request for and decide there whether you want to bind an entry point to it rather than treat it as a file ? > My own *.wt app itself does serve pages, in the usual way (--docroot > etc.), thus it is properly executable. > Since webtoolkit.eu is said to be Apache-based, I assume it is no > problem there due to using FastCGI. So webtoolkit.eu actually switched to wthttpd a few years ago (mainly because deployment is simpler). > Strongly contemplating going to git trunk if that improves it > (in case single-instance issued fixed or so) If you want to serve multiple applications from different URLs, but it is okay if they are served from the same port (e.g. 80 or 8080), then I think the single-instance config should be no problem. I guess you are mainly looking for better interaction with the server allowing you to bind an entry point to a new 'createApplication' callback which you dlopen() from a plugin, right ? So far we have never allowed much more intelligence with WServer simply because connectors such as FastCGI will never allow much intelligence there (it is totally reliant on the configuration of your web server). > So far I have to say Wt is absolutely incredible, > extremely convincing code quality and awesome layering concept. > >From my Free Software Fascist (tm) POV, the license (dual licensing) > is perfect too: Proprietary whimps pay dearly (and get good support services, > hopefully), whereas GPL projects get everything for free (with less stringent > support obviously ;). Yes, GPL users get a 7 day delay in getting questions answered. :-) Regards, koen ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ witty-interest mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/witty-interest
