critique of vibe.d

[Sönke Ludwig via Digitalmars-d]

Am 09.07.2014 19:03, schrieb Johannes Pfau:
> 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?

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