critique of vibe.d

[Rikki Cattermole via Digitalmars-d]

On 10/07/2014 9:12 a.m., Johannes Pfau wrote:
> Am Wed, 09 Jul 2014 20:34:49 +0200
> schrieb Sönke Ludwig <sludwig at rejectedsoftware.com>:
>
>> 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
>
> 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 ;-)

Unfortunately right now Cmsed doesn't for-fill its purpose in the CMS 
area. But basically I use dub sub packages so if you didn't want to go 
full in, you didn't need to.
I.E. the base web service framework is literally called cmsed:base and 
it would give you most of the nice ness e.g. router, javascript 
generation and Dvorm integration (ORM and works rather well in my opinion).
Where as cmsed:user would provide just user authentication and storage 
mechanism.