Introducing vibe.d!

[James Miller]

On Monday, 7 May 2012 at 18:51:26 UTC, Sönke Ludwig wrote:
> I think one of us (Jan) has something for better form handling 
> locally, not yet committed, and I would count that as something 
> that would still fit well into the core package. But in 
> general, I think the number of features should not grow too 
> much anymore - the core should contain all that is necessary 
> for _most_ applications and that with an interface that is as 
> comfortable as possible.
>
> The main scope of modules, I would say, are higher level 
> features, features that are not as widely used or those which 
> provide alternatives to the functions in the core library. 
> Basic, common functionality, however, is always a candidate for 
> the core (OAuth(2) is on the way for example).
>
> Another - quite banal - criterion could be if we would actually 
> use a feature ourselves, at least a bit; simply because if we 
> don't use it, we cannot test it without further time 
> investments and it could be unclear (to us) how well such a 
> component actually works (e.g. wrt. stable releases). Also, the 
> implementation/API style of a feature should match the rest of 
> the core library. The MySQL driver would be an example that 
> currently fails both criterions and thus is a module.
>
> Maybe it would also be good to establish a defined procedure 
> such as: New features are implemented as modules first and 
> after a review it's decided if they should go in for the next 
> release. I don't have a real opinion on this yet and I'm 
> basically completely open for suggestions.

Sound good, now I'm just hoping that porting my forms stuff to 
the core forms isn't going to be too hard :D.

Otherwise it seems you have a rough idea of what constitutes a 
module and what is a feature, and that is a good start. I think 
an informal review process for module -> feature promotion would 
be good, since then the code can be available for use earlier. 
Also, there is something to be said for making "official" vibe 
modules, ones maintained, or at least, approved by the vibe team 
and given slightly more prominence. This can keep the core system 
small, but still allow the vibe team to provide more 
functionality, especially if it is common functionality.

--
James Miller