Hi, On Mon, Feb 08, 2010 at 01:14:20PM +0100, Koen Deforche wrote: > 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 ?
'restart' is the one I'm trying to avoid (rebuild is partial already, since it's a decoupled library). > > 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 ? wthttp. > > 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. OK. So I was trying to figure out how it is setup there: - Apache is strictly used as redirector - redirects go to _running_ wthttpd:s (e.g. hello.wt, ...) in case any of the example URLs gets hit - and this is done as a virtual hosts setup, using usual port 80 If so, then I'm afraid I cannot model it this way since with my current setup my entire app basically is one running wthttpd, and there isn't anything runtime-modifiable. > 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 ? Yes, having a createApplication() implementation which dlopen()s an app plugin would be the only feasible way for me now, but OTOH this doesn't buy me anything either since there's no destroyApplication() callback, thus lifetime of the dlopen() is unknown and the plugin library would remain loaded forever, thus any rebuilds of that plugin library (in order to provide updates to the WApplication) won't make their way into the running process. IOW, I'm still stuck with tearing down the entire running process in order to serve my rebuilds. It's not terribly painful (maybe 10 seconds each), but a nuisance given those repetitions during the development cycle. Thanks a lot for your helpful reply! Andreas Mohr ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev _______________________________________________ witty-interest mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/witty-interest
