critique of vibe.d

[Johannes Pfau via Digitalmars-d]

Am Wed, 09 Jul 2014 18:16:49 +0200
schrieb Sönke Ludwig <sludwig at 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?

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.