Am Wed, 09 Jul 2014 18:16:49 +0200 schrieb Sönke Ludwig <[email protected]>:
> 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? 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.
