critique of vibe.d

[Chris via Digitalmars-d]

On Thursday, 10 July 2014 at 10:24:23 UTC, Dicebot wrote:
> On Wednesday, 9 July 2014 at 21:07:26 UTC, Johannes Pfau wrote:
>> Am Wed, 09 Jul 2014 17:28:42 +0000
>> schrieb "Dicebot" <public at dicebot.lv>:
>>
>>> On Wednesday, 9 July 2014 at 17:05:21 UTC, Johannes Pfau 
>>> wrote:
>>> > 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?
>>> 
>>> What is the benefit as opposed to using proxy_pass at nginx? 
>>> fcgi will be slower than built-in vibe.d HTTP server.
>>
>> FCGI was only an example. I guess the only benefit is that the 
>> webserver
>> can spawn fcgi backends when it starts and files with certain
>> extensions can be handled with these backends.
>>
>> But that's of course only useful with shared libraries / pages.
>
> vibe.d can do it internally by having different routes for 
> different file types and doing dynamic load if desired. Being 
> 100% independent of HTTP server frontend is a big feature in my 
> opinion.

Yes, that's what I use. I have this in my vibe.d code (to solve 
the problem that Chrome/Chromium play sound files only once):

router.get("*.wav", &handleAudioRequest);

private void handleAudioRequest(HTTPServerRequest req, 
HTTPServerResponse res) {
   res.headers.addField("Accept-Ranges", "bytes");
}