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
