Am Wed, 09 Jul 2014 20:34:49 +0200 schrieb Sönke Ludwig <slud...@rejectedsoftware.com>:
> Am 09.07.2014 19:03, schrieb Johannes Pfau: > > Am Wed, 09 Jul 2014 18:16:49 +0200 > > schrieb Sönke Ludwig <slud...@rejectedsoftware.com>: > > > >> Am 09.07.2014 17:26, schrieb Sean Kelly: > >>> On Wednesday, 9 July 2014 at 01:33:01 UTC, Puming wrote: > >>>> Also, in playframework, vert.x and nodejs, they all have a > >>>> plugin/module system, that people could easily compose plugins to > >>>> make a website. (I call it plugin because that is what play used > >>>> to call it, now they all call it a module but that name will > >>>> easily conflict with D's sourcecode modules). This is a critical > >>>> mechanism that actually allured developers to contribute to the > >>>> eco-system. > >>> > >>> On a related note, one thing vibe.d is really missing from my > >>> perspective is a good way to handle unstable processes and perform > >>> seamless code upgrades (this is where Erlang really shines IMO). > >>> It would be cool if there were a process monitor at least. The > >>> system I work with does some fancy stuff with UDS, but that > >>> probably isn't necessary. I'll admit that the ball is probably > >>> kind of in my court here, since IPC would be a handy way of > >>> communicating process health, but something simpler using pipes > >>> or whatever would work as well. > >> > >> This is what vibedist [1] was/is intended for, but unfortunately I > >> never found the time to really finish it so far. > >> > >> [1]: https://github.com/rejectedsoftware/vibedist > > > > > > Completely off-topic, but: > > > > Have you considered making vibe http-backend independent? > > So that it could provide a fcgi interface or be included in an nginx > > plugin? > > That could be done pretty easily by providing an alternative to > listenHTTP() (e.g. void listenFCGI(HTTPServerRequestDelegate del)). > It could use the HTTPServerRequest and HTTPServerResponse classes > more or less just like the HTTP server does. > > > > > Also as D plugins now seem to work more or less have you considered > > loading webpages dynamically from .so files? > > > > Then we could invent some file extension - like .dpage - and have > > one vibe fcgi process handle all .dpage files. The process then > > simply loads the .dpage shared library, calls some function > > (extern(C) IWebSite vibe_get_site()) etc. > > > > Basically the way asp.net works, IIRC. > > > > That would be pretty much what Rikki Cattermole is planning to do > with Cmsed [1]. For vibe.d it would be a bit too much at this time. > There is still a lot that I would like to get done on the lower > levels of the library, so that the basis is really solid sooner > rather than later. The highest level features planned for now are the > descriptive REST and web interface modules. > > However, there is a plan for using dynamic libraries to support > seamless live editing/reloading of individual Diet templates [2]. > > [1]: http://code.dlang.org/packages/cmsed > [2]: https://github.com/rejectedsoftware/vibe.d/issues/676 I see, thanks. I think a CMS is usually a little higher-level then what I meant. But of course a name doesn't say much about what a project actually is ;-)
