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.
Plugins are like dub packages in a way, but not exactly. Dub
packages are an encapsulation of build packages, which is similar
to Java's maven packages. But plugins are components of the web
framework, built on top of build packages, but has more
application related meaning. So both play and vert.x have
separated plugin(in vert.x is called a module) concept from maven
package. Vibe.d could have this plugin mechanizem, but Sonke said
that it should be the responsibility of a framework on top of it
(meaning in that framework, vibe.d would just be a plugin to the
framework that web developers would choose to server http
requests).
For example, if one designed a user/password plugin, with
database access logic (in source folder), login page templates
(in view folder) and static js/image/css (in public folder), and
this plugin is used, then all resources are treated just as they
are manually put into respective folders. While dub packages
usually only deals with D code.
You can see playframework's plugin registery here:
<http://www.playframework.com/documentation/2.3.x/Modules>
vert.x module's document here:
<http://vertx.io/mods_manual.html>, vert.x has a more complicated
module design (which not only is a way to group functionalities,
but also a deployment node).
its registery here: <http://modulereg.vertx.io/>
On Wednesday, 9 July 2014 at 01:09:10 UTC, Puming wrote:
Vibe.d is more like a base library for async I/O, networking
and concurrency, a full stack WEB framework should be built on
top of it which focus on application development and ease of
use for newcomers. Sonke has said that too. Vibe.d should focus
on performance, networking, and other lowerlevel stuff that D
should be really good at. Sonke is already too busy doing his
gorgeous work on vibe.d and dub. I think that is what the guy
on reddit was complaining, he thought vibe.d should contain
everything from a web framework, but didn't find them, thus
getting the impression that vibe.d was not complete. Actually
vibe.d is just an edge of a triangle in web frameworks. We are
lacking the other two pieces.
We need a MVC or whatever framework on top of it. Compared to
Java world, there is [Netty](http://netty.io) the networking
library and Web frameworks like playframework, vert.x built on
top of it.
Currently the only work that is active IFAIK is Rikki's
[CMSED](https://github.com/rikkimax/Cmsed), which needs more
love.
In [playframework](http://playframework.org), incoming request
are send to a cluster of actions in a [Akka](http://akka.io)
cluster for computing & business logic. The trio (play, netty &
akka) has shown to be very good combination for a web stack.
We have actor models in std.concurrency but only with thread
granularity, vibe.d has got a fiber based concurrency model
which I think could go in to the standard library, or make its
own library. That front needs more manpower. Again, rikki has
initiated a port from akka --
[dakka](https://github.com/rikkimax/dakka). I think it is a
right way to go.
On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu
wrote:
There's been some discussion about vibe.d recently on reddit
(e.g.
http://www.reddit.com/r/programming/comments/2a20h5/wired_magazine_discovers_d/cir9443)
and I was wondering to what extent that's meaningful:
"has anyone ever tied a real webservice to vibe.d? I actually
tried. its nowhere near complete in any sense. you simply
cannot compare it with go's standard http lib, sorry, I tried."
If there's sheer work needed for completing vibe.d, I think it
would be great if the domain-savvy part of the community would
rally around it. Serving dlang.org and dconf.org off of vibe.d
would be awesome dogfooding.
Andrei