Am 27.04.2012 11:06, schrieb Nick Sabalausky:
> "Sönke Ludwig"<sludwig@outerproduct.org>  wrote in message
> news:jndl9l$26eh$1@digitalmars.com...
>>
>> We still have a more comprehensive benchmark on the table but it seemed to
>> get along happily with about 60MB of RAM usage during a C10k test. The
>> average request time went down to about 6s if I remember correctly. The
>> test was using a dual-core Atom server over a WiFI connection so the
>> results may have been skewed a litte.
>>
>
> I guess I don't have much of a frame of reference, but that certainly sounds
> very impressive. Especially the RAM usage (you could probably kill lighttpd,
> from what I've heard about it) and also the fact that was all over WiFi.
>
> Have you looked at long-term memory usage? I wonder if D's imprecise GC
> could be a liability and would need to be ?

I'm starting to monitor it now. Directly after startup, the website is at 32 MB. The traffic has dropped a bit but hopefully it's enough to see something if there is a hidden leak.

After the C10k test, the memory usage dropped back to normal if I remember right so there should be nothing too bad in the core.

>
>> In terms of HTTP/1.1 implementation it is most importantly lacking
>> multipart form uploads (will be added shortly). Otherwise the protocol
>> supports most HTTP features. I'll put a more detailed comparison on my
>> TODO list.
>>
>
> Thanks, I'm anxious to take a look. I'm particulary curious how much of your
> intended scope does/doesn't overlap with Nginx's domain and it's (rather
> Apache-competetive) suite of modules: http://wiki.nginx.org/Modules
>
From going just over the module index, the features that are in or planned are:

 - most of Core is there
 - Basic auth - check
 - Auto index - part of a separate library that is still in dev.
 - FastCGI client is planned, possible also a server
 - Gzip responses (the static file server componen does this)
 - Headers - check
 - Limit Requests/Zone is planned
 - Limit Conn is planned
 - Log - check
 - Proxy - check
 - scgi - maybe instead of FastCGI
 - Split Clients - easy to do programmatically
 - Upstream - planned
 - SSL - check
 - WebDAV - planned
 - simplistic SMTP - check

> Do you see this as eventually (or even currently) competing with Nginx in
> general? Or is it more focused on web framework and general async I/O?
> (Actually that's another thing, how general is the async I/O in it? Is it
> intended to be used for just...whatever general I/O uses...or is it more
> intended as a means-to-an-end for web?)
>
> The way it's designed, I suppose the features of many of Nginx's modules
> could simply be implemented using vibed, for example directory listings.
>


In general it's more a general application framework or an extension library. But a stand-alone webserver would be an easy project - nothing that I have directly planned myself though.

The I/O is supposed to be as general as possible. Right now the focus has been on web applications but we also plan a desktop application that is going to use it for all of its I/O. For this I'm also looking into how to integrate the event loop with the OS message queue efficiently on all platforms.

There are still some things missing for the libevent driver but with the upcoming libuv driver everything that libuv provides should be available.

Am 27.04.2012 10:26, schrieb Andrej Mitrovic:
> On 4/27/12, Sönke Ludwig<sludwig@outerproduct.org>  wrote:
>> Now I changed the line "SET LIBDIR=..\lib\win-i386" in run_example.cmd
>> from quoted to non-quoted and for me it seems to work.
>
> Maybe try:
> SET "LIBDIR=..\lib\win-i386"
>
> IOW quotes after SET.

Thanks, that also seems to work. I will try that next as soon as the current non-quoted version fails for someone.

I am not sure if you're aware of Flask, Flask is a microframework for Python.

It provides something called "Blueprints", you can register e.g. "routes" to this Blueprint and to use them you've to add them to the main application. This makes code way more readable!
Also some kind of after_request and before_request handlers would be great, you could use them e.g. fetching a user from the database and providing it to the handler (over a thread-local?).

Can't wait to go home and get my greedy hands on it.
Sounds.. amazing. Hell, if all of this stuff really works and works on par with nginx+fastcgi performance, it can be the very killer app for D waited so long.

Excellent work Sönke! Vibe.d seems very promising :)

I've played with vibe.d with a hello project as described in the
document, and downloaded vibenotes and vibeblog from git and
poked around a little.

vibe.d gives me a very smooth experience, and I'll try learn
about it more :)

two little things to note:

1. In the tutorial it didn't say how to start vibe.d project. I
spent some minutes to find it: by running vibe at the root of a
project. Maybe its clear to state that in the tutorial

2. It seems that diet templates doesn't support soft tab. I
looked into the code, and in indentLevel(line) it only dectects
'\t'. Will vibe.d support soft tab?

Am 27.04.2012 11:57, schrieb David:
> I am not sure if you're aware of Flask, Flask is a microframework for
> Python.
>
> It provides something called "Blueprints", you can register e.g.
> "routes" to this Blueprint and to use them you've to add them to the
> main application. This makes code way more readable!
> Also some kind of after_request and before_request handlers would be
> great, you could use them e.g. fetching a user from the database and
> providing it to the handler (over a thread-local?).

I didn't know flask before and the website seems to be down currently ;)

But is the UrlRouter (see http://vibed.org/docs#http-routing and http://vibed.org/api/vibe.http.router#UrlRouter) something equivalent?

It allows you to specify multiple patterns that are matched in sequence until a request handler writes a response:

auto r = new UrlRouter;
r.any("*", &performAuth);
r.get("/", &renderHomePage);
listenHttp(settings, r);

This would first always match performAuth, which could check the user credentials and write out a message if the user is not authenticated. Otherwise it just does nothing and the router will continue to the next match, which is renderHomePage() in this case for "GET /".

Whats not directly possible in the router is something like after_request. But you can do it easily by wrapping the call:

auto r = new UrlRouter;
//...
listenHttp(settings, (req, res){
	before_request(req, res);
	r.handleRequest(req, res);
	after_request(req, res);
});

Am 27.04.2012 13:07, schrieb Puming:
> Excellent work Sönke! Vibe.d seems very promising :)
>
Thanks :)

> I've played with vibe.d with a hello project as described in the
> document, and downloaded vibenotes and vibeblog from git and
> poked around a little.
>
> vibe.d gives me a very smooth experience, and I'll try learn
> about it more :)
>
> two little things to note:
>
> 1. In the tutorial it didn't say how to start vibe.d project. I
> spent some minutes to find it: by running vibe at the root of a
> project. Maybe its clear to state that in the tutorial

It definitely needs some improvements. My idea would be to change it to a step-by-step tutorial and also add support for something like "vibe init <appname>" to generate the basic app skeleton.

>
> 2. It seems that diet templates doesn't support soft tab. I
> looked into the code, and in indentLevel(line) it only dectects
> '\t'. Will vibe.d support soft tab?

I put an item in the TODO list to detect the indent style from the first indented line. This indent style would then be used for the rest of the document.

Am 27.04.2012 13:18, schrieb Sönke Ludwig:
> Am 27.04.2012 11:57, schrieb David:
>> I am not sure if you're aware of Flask, Flask is a microframework for
>> Python.
>>
>> It provides something called "Blueprints", you can register e.g.
>> "routes" to this Blueprint and to use them you've to add them to the
>> main application. This makes code way more readable!
>> Also some kind of after_request and before_request handlers would be
>> great, you could use them e.g. fetching a user from the database and
>> providing it to the handler (over a thread-local?).
>
> I didn't know flask before and the website seems to be down currently ;)

Yes :(
Admin paused the server, too much IO or something.

> But is the UrlRouter (see http://vibed.org/docs#http-routing and
> http://vibed.org/api/vibe.http.router#UrlRouter) something equivalent?
>
> It allows you to specify multiple patterns that are matched in sequence
> until a request handler writes a response:
>
> auto r = new UrlRouter;
> r.any("*", &performAuth);
> r.get("/", &renderHomePage);
> listenHttp(settings, r);
>
> This would first always match performAuth, which could check the user
> credentials and write out a message if the user is not authenticated.
> Otherwise it just does nothing and the router will continue to the next
> match, which is renderHomePage() in this case for "GET /".

This is useful!

> Whats not directly possible in the router is something like
> after_request. But you can do it easily by wrapping the call:
>
> auto r = new UrlRouter;
> //...
> listenHttp(settings, (req, res){
> before_request(req, res);
> r.handleRequest(req, res);
> after_request(req, res);
> });

Awesome!

On Friday, 27 April 2012 at 08:47:23 UTC, Sönke Ludwig wrote:
> Initially I wanted to have a page-comment feature ready as on dlang.org. But for now I guess the github issue tracker should do the job: https://github.com/rejectedsoftware/vibe.d/issues

Oh, and another thing, is vpm live yet? I though about starting to hack on a Socket.io implementation for Vibe this weekend…

David

Am 27.04.2012 13:57, schrieb David Nadlinger:
> On Friday, 27 April 2012 at 08:47:23 UTC, Sönke Ludwig wrote:
>> Initially I wanted to have a page-comment feature ready as on
>> dlang.org. But for now I guess the github issue tracker should do the
>> job: https://github.com/rejectedsoftware/vibe.d/issues
>
> Oh, and another thing, is vpm live yet? I though about starting to hack
> on a Socket.io implementation for Vibe this weekend…
>
> David

It's live but currently projects can only be registered manually and there is no user web frontend - not a big deal though. But it still needs some testing and misses some features (e.g. package signing, updating and machine-wide installs).

Btw. there is already a WebSocket implementation in vibe.http.websockets, although still undocumented (vibenotes uses it). Jan, who has written it also planned on doing a fallback for older browsers using long polling. But socket.io compatibility was not on the table yet..