Introducing vibe.d!

[Sönke Ludwig]

Am 07.05.2012 01:12, schrieb James Miller:
> I'm currently building a site in vibe and love it. There are still a few
> bugs around, and a few useful features to come, but I've been patching
> and writing features as I go, so its all good.
>
> I am curious about your policy on big features though, I have been
> working an implementation for using forms simply. Its nowhere near being
> ready for release yet, but is it the kind of thing you'd want as a
> module, or as a part of the main vibe codebase? There are also a lot of
> more producing-friendly features that could be done (IOW, allowing
> fine-grained configuration of server params, and supporting 8 different
> load-balancing schemes is great, but doesn't help me produce a
> website...), would they be mostly modules, or more core parts?
>
> --
> James Miller

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.