April 28, 2012
[my previous anwer got lost because of an high-load error on the NG server. hope I didn't forget anything..]

Am 27.04.2012 21:40, schrieb F i L:
> Sönke Ludwig wrote:
>> During the last few months, we have been working on a new
>> framework for general I/O and especially for building
>> extremely fast web apps. It combines asynchronous I/O with
>> core.thread's great fibers to build a convenient, blocking
>> API which can handle insane amounts of connections due to
>> the low memory and computational overhead.
>>
>> Some of its key fatures are:
>> ...
>
> vibe.d looks great! Looking through the docs, it feels clean and "hip"
> like node.js
>
> However, there are a couple refactoring choices I think would have made
> it even more "hip", consider the home page example:
>
> import vibe.d;
>
> void handleRequest(HttpServerRequest req,
> HttpServerResponse res)
> {
> res.writeBody("Hello, World!", "text/plain");
> }
>
> static this()
> {
> auto settings = new HttpServerSettings;
> settings.port = 8080;
>
> listenHttp(settings, &handleRequest);
> }
>
> "vibe.d" as the project name is great, but why have module vibe.d and
> not simply vibe? Or, why prefix all the types with "HttpServer" when you
> could separate those objects into a new module and drop the prefix. I
> think those simple changes would make an already polished library shine
> a bit brighter:
>
> import vibe.http;
>
> void handleRequest(Request req, Response res) {
> res.writeBody("Hellow, World!", "text/plain");
> }
>
> static this() {
> auto settings = new Settings;
> settings.port = 8080;
>
> listen(settings, &handleRequest);
> }
>
> the echo server would look like:
>
> import vibe.tcp;
>
> static this()
> {
> listen(7, (conn){ conn.write(conn) });
> }

The objects are already in different modules, albeit a level deeper (e.g. vibe.http.server). "import vibe;" cannot currently work without something like DIP15 or DIP16 because vibe is a package.
-> http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs

There are two reasons, why I made the names unique: readability/understandability and ease of use (not having to look up all the sub modules to find a certain function).

I am not really happy with the long names but on the other hand I found this was not really much of an issue, because often you can avoid it alltogether with things like staticTemplate!"file.dt" (http://vibed.org/api/vibe.http.server#staticTemplate) or by using a closure with inferred parameter arguments.

>
> Also, it's great to see MongoDB support built in :D, but isn't there a
> way to trim down the query object from:
>
> BSON({"name": BSON("Peter")})
>
> to:
>
> BSON({"name":"Peter"})
>
> by writing a generic AssosiativeArrayToBSON function? That way you could
> overload MongoDB's find/save/etc functions to accept arbitrary AAs as
> queries, which would end up looking a lot slicker in the docs I think.
> Plus, through CTFE it's possible this conversion could happen at both
> compile-time and run-time:
>
> auto db = new MongoDB;
> auto col = db["test.collection"];
>
> foreach (doc; col.ctFind!(["name":"Peter"])) {
>
> ...
> }

The MongoDB functions can actually take any of Bson, Json, Bson[ObjectID,Date,...], arrays, AAs, strings and scalars and structs and classes, in any nesting. They use serializeToBson() internally to convert to Bson.

The examples and the documentation need some updates there.

>
> Just some ideas in case you haven't thought of them already :)
>
>
> Overall vibe.d looks like a fantastic library. Thank you and Congrats!

Thanks! I hope the remaining rough edges get smoothed out quickly in the next time.
April 28, 2012
Am 27.04.2012 11:34, schrieb Sönke Ludwig:
>
> 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.
>

A mid-term test now shows that shortly after startup the virtual memory usage went up from 32MB to about 44MB. After 24h and about 50k requests it stays at 43.5MB. Real memory usage is 15MB.
April 28, 2012
Awesome! that was one of my concerns with D in general with server software
and its long running nature.
I've been thinking about fibers and socket.d this week. Glad you anounced
this before I started working on something :D.

How difficult would it be for you to split the async IO parts into a separate library? This would be very much like gevent (python: http://www.gevent.org/).

Any chance of supporting WSGI?

On Sat, Apr 28, 2012 at 2:36 PM, Sönke Ludwig <sludwig@outerproduct.org>wrote:

> Am 27.04.2012 11:34, schrieb Sönke Ludwig:
>
>
>> 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.
>>
>>
> A mid-term test now shows that shortly after startup the virtual memory usage went up from 32MB to about 44MB. After 24h and about 50k requests it stays at 43.5MB. Real memory usage is 15MB.
>


April 29, 2012
Very nice to see that someone took the async/Fiber idea that far.

Some observations:
- Wouldn't wrapping code in "void main()" instead of "static this()" make better front page examples.
- It would be interesting to know what made you write your own Stream/JSON implementations.
- I think there is some interest in having the HTTP handling and the templates in a separate library.
April 29, 2012
Great job. Thanks Soenke et al;

>  - Built-in support for MongoDB and Redis databases

MySQL.
Like other folks here I need a SQL db, At least for MyQL 5.1 there is a socket based solution from Steve Teale.
https://github.com/britseye/mysqln
Means no licence trouble, and probably easier to establish async support.

Quote
Additional drivers are easy to port to vibe.d because of the blocking API - basically the only thing that has to be done is to replace the socket calls (send(), recv(), connect() etc.) with the corresponding vibe functions.
EndQuote

Can you elaborate a bit more ? Maybe using the vibe.d blog.

There is also a socket based PostgreSQL driver available, but I have lost the link and dunno about the status quo.

----
A MIT licenced *D2 crypto lib worth a look :
http://www.dsource.org/projects/dcrypt/wiki/Features

*not up to date

----
Whishes:
diet template documentation.
diet template javascript example
server side QR-code generation.  (well may be I am able to contribute)
April 29, 2012
Am 29.04.2012 06:18, schrieb Martin Nowak:
> Very nice to see that someone took the async/Fiber idea that far.
>
> Some observations:
> - Wouldn't wrapping code in "void main()" instead of "static this()"
> make better front page examples.

The static this() pattern is mainly there to appeal to users of similar systems in script languages, where you don't have a main function at all and just happily hack away. For larger projects it doesn't make a difference but for small projects it can actually be quite convenient.

Maybe it would be a good idea to place a prominent example of how it's possible to define your own main() to gain additional control.

> - It would be interesting to know what made you write your own
> Stream/JSON implementations.

Stream has a number of additional functions or parameters such as leastSize() that are required or extremely convenient in this context. Also to avoid dragging in something like std.stream.File which has sychronous behavior and would block the event loop without anyone noticing it until the resulting bad performance under high-load conditions shows.

The reasons for writing an own Json implementation is that the interface of std.json is.. well.. nice if you write something in C. The implementation in vibe tries to let Json seem like a natural dynamic type of the language as far as it makes sense. The std.json parser can also only parse string buffers and I wanted to have something that can easily be used to work efficiently on a stream. Support for pretty printing was another reason (would of course also easy to add on top of std.json).

> - I think there is some interest in having the HTTP handling and the
> templates in a separate library.

My considerations are that if you don't use the HTTP/... parts, it will neither occupy space in your app, nor will it drag in any additional dependencies. That separate library would basically be vibe.core and vibe.stream vs. the rest of modules. And dependency-wise they are already separate (core and stream have no outside dependencies to the library).

If on the other hand you wanted to use the HTTP/... stuff together with other libraries in a blocking, non-fiber environment, it would also just work - all operations are also working and blocking outside of the event loop.
April 29, 2012
Am 29.04.2012 08:13, schrieb bls:
> Great job. Thanks Soenke et al;
>
>> - Built-in support for MongoDB and Redis databases
>
> MySQL.
> Like other folks here I need a SQL db, At least for MyQL 5.1 there is a
> socket based solution from Steve Teale.
> https://github.com/britseye/mysqln
> Means no licence trouble, and probably easier to establish async support.

This looks like an ideal starting point. The license is of course very similar to the MIT license, but I would like to keep everything in the core library under a uniform license. Otherwise it could of course also be a VPM package. But in general this looks so simple to port that I would even just do it if no one else wants to have a shot.

>
> Quote
> Additional drivers are easy to port to vibe.d because of the blocking
> API - basically the only thing that has to be done is to replace the
> socket calls (send(), recv(), connect() etc.) with the corresponding
> vibe functions.
> EndQuote
>
> Can you elaborate a bit more ? Maybe using the vibe.d blog.

Good idea, it will put something together.

>
> There is also a socket based PostgreSQL driver available, but I have
> lost the link and dunno about the status quo.
>
> ----
> A MIT licenced *D2 crypto lib worth a look :
> http://www.dsource.org/projects/dcrypt/wiki/Features
>
> *not up to date

Looks nice. If it had support for SSL/TLS, we could even drop the libssl dependency. However, I'm currently leaning towards just wrapping libcrypto since we need it anyway for libssl and it's actively maintained.

>
> ----
> Whishes:
> diet template documentation.

This is the next point on the documentation todo list.

> diet template javascript example

I will add one. You can use something like
head
	:javascript
		function myFunction(){
			...
		}
But this was just added yesterday so you need a current GIT snapshot.

> server side QR-code generation. (well may be I am able to contribute)

Would be great. If you want, you could also make a github repository for this with a package.json file and I will put it into the VPM registry. The registry is currently still a manual process but it will be extended so that anyone can register and publish packages. Some features such as package signing are still missing for that.
April 29, 2012
On Sun, 29 Apr 2012 08:13:40 +0200, bls <bls@orange.fr> wrote:

>
> There is also a socket based PostgreSQL driver available, but I have lost the link and dunno about the status quo.

This? https://github.com/pszturmaj/ddb
April 29, 2012
On Sun, 29 Apr 2012 10:31:07 +0200, Sönke Ludwig <sludwig@outerproduct.org> wrote:

> Quote
> Additional drivers are easy to port to vibe.d because of the blocking
> API - basically the only thing that has to be done is to replace the
> socket calls (send(), recv(), connect() etc.) with the corresponding
> vibe functions.
> EndQuote
>  Can you elaborate a bit more ? Maybe using the vibe.d blog.
>  Good idea, it will put something together.

Something wrong with the blog engine? The published post doesn't show in the list, and it's cut off in the middle without any way to expand it: http://vibed.org/blog/posts/writing-native-db-drivers
April 29, 2012
On 2012-04-29 10:07, Sönke Ludwig wrote:

> The static this() pattern is mainly there to appeal to users of similar
> systems in script languages, where you don't have a main function at all
> and just happily hack away. For larger projects it doesn't make a
> difference but for small projects it can actually be quite convenient.

Since you can't have code (besides declarations) at the module level I don't see how "static this" would be than "main".

-- 
/Jacob Carlborg