Actually there is already software that does such a thing for ruby on rails, it is called [guard](https://github.com/guard/guard).
Mainly it watches the filesystem of the app folder and detects changes in config files, controller classes, database, etc and (re-)runs tests, (re-)starts server (if necessary) and much more. It should be possible to write a guard for it that watches a project dir and then rebuilds the witty binary and restart the http. Deploying a fcgi binary would be a bit harder, because restarting a web server often requires to be root, so your workflow would be interrupted by entering root passwords every time sudo times out, but generally it should be possible. 2014-03-28 2:21 GMT+01:00 Jason H <scorp...@yahoo.com>: > I've been thinking about your comments. and I think I have something that > is better, but different. > > While existing maintenance is probably done best as you described, I'm > still looking for an easier way to iteratively develop "pages" (for lack of > a better term). My idea is currently that upon saving a C/Cpp file, the > binary should rebuild the object file and unload/insert itself into the > server. I don't know if it is possible to have each object file do that > automatically. But with a fast enough system I should be able to hit "save" > and by the time I hit reload in the browser the new code (object or whole > new binary) should be up and running. However, in my tests with my core i5, > when also debugging I sometimes beat it. > > So I think that would be cool. Integrate a file system watcher with make. > > > ------------------------------ > *From:* Wim Dumon <w...@emweb.be> > *To:* witty-interest@lists.sourceforge.net > *Sent:* Thursday, March 27, 2014 10:28 AM > *Subject:* Re: [Wt-interest] witty application upgrade? > > In fact, this can theoretically be done with a reverse proxy, and > using Wt's session prefix feature. Use a different prefix for old and > new sessions, and forward requests accordingly. I've never done this. > > BR, > Wim. > > > 2014-03-27 10:41 GMT+01:00 Koen Deforche <k...@emweb.be>: > > Hey Jason, > > > > 2014-03-26 21:57 GMT+01:00 Jason H <scorp...@yahoo.com>: > >> > >> How would someone do an upgrade? It seems that we have to stop > everything > >> and start everything for a witty application? > >> Or, could witty somehow maintain more than one application at a time, > and > >> when a newer one comes along, be messaged to use the new one for new > >> connections? And as sessions are [re]started, move to the new while > current > >> sessions remain on the old implementation or are signaled to gracefully > >> restart the session. Also how is session data handed off between > upgrades? > > > > > > Currently people are shutting down while upgrading; with a static page to > > announce the upgrade (as Norbert suggests). > > > > The above functionality has been an idea we have had since long as > something > > that would be very nice to have, but it turns out that in practice > everyone > > seems happy without it. To implement the above we would need a reverse > proxy > > server that knows enough of Wt's session management to direct new > sessions > > to an upgraded server while old server instances continue to run the old > > code until all of their sessions are done. A http reverse proxy is > however > > not a trivial implementation. > > > > Moreover, if you really want, you can get the above behaviour using Wt's > > FastCGI dedicated process deployment as then for each new session a new > > process is spawned. > > > > Regards, > > koen > > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > > witty-interest mailing list > > witty-interest@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/witty-interest > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > witty-interest mailing list > witty-interest@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/witty-interest > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > witty-interest mailing list > witty-interest@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/witty-interest > >
------------------------------------------------------------------------------
_______________________________________________ witty-interest mailing list witty-interest@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/witty-interest
