May 03, 2012
On Thursday, 3 May 2012 at 09:22:23 UTC, bls wrote:
> Should be POST GET PUT DELETE

I'm afraid, some proxies may cut unusual http verbs. SVN relies on them and if a proxy is not nice, it gets broken.
May 06, 2012
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
May 07, 2012
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.

May 09, 2012
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
May 19, 2012

How do a manual install on linux ?
I am a fedora user they are no specialized or common install
documentation!

May 19, 2012
Am 19.05.2012 12:50, schrieb bioinfornatics:
>
>
> How do a manual install on linux ?
> I am a fedora user they are no specialized or common install
> documentation!
>

Something like

yum install libevent-devel
yum install openssl-devel

instead of "apt-get install libevent-dev openssl-dev" should work. You then only need dmd (with rdmd) installed and unzip or git clone vibe. You can then optionally put a symbolic link in /usr/bin:

ln -s /path/to/vibe/bin/vibe /usr/bin/vibe

Hope this helps.

(if it does, I will add it as instructions to the README)
November 04, 2013
Hi Sönke,


Congratulations for your hard work.


One question,
How do you think your framework running in development mode where a huge amount of models with many business rules exist. A system under development can be slow, like java where a signature change in the method requires reload of the whole application.

Alexandre Riveira


On Thursday, 26 April 2012 at 20:46:41 UTC, 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:
>
>  - Very fast but no endless callback chains as in node.js
>    and similar frameworks
>  - Concise API that tries to be as efficient and intuitive
>    as possible
>  - Built-in HTTP server and client with support for HTTPS,
>    chunked and compressed transfers, keep-alive connections,
>    Apache-style logging, a reverse-proxy, url routing and
>    more
>  - Jade based HTML/XML template system with compile-time
>    code generation for the fastest dynamic page generation
>    times possible
>  - Built-in support for MongoDB and Redis databases
>  - WebSocket support
>  - Natural Json and Bson handling
>  - A package manager for seemless use of extension libraries
>
> See http://vibed.org/ for more information and some example
> applications (there are some things in the works such as an
> etherpad clone and an NNTP server).
>
> vibe.d is in a working state and enters its first beta-phase
> now to stabilize the current feature set. After that, a
> small list of additional features is planned before the 1.0
> release.
>
> The framework can be downloaded or GIT cloned from
> http://vibed.org/ and is distributed under the terms of the
> MIT license.
>
> Note that the website including the blog is fully written
> in vibe and provides the first stress test for the
> implementation.
>
> Regards,
> Sönke

November 04, 2013
On Monday, 4 November 2013 at 16:40:25 UTC, Alexandre Riveira
wrote:
> Hi Sönke,
>
>
> Congratulations for your hard work.
>
>
> One question,
> How do you think your framework running in development mode where a huge amount of models with many business rules exist. A system under development can be slow, like java where a signature change in the method requires reload of the whole application.
>
> Alexandre Riveira

Alexandre,
Vibe.D now has its own forum, might be a better place to post
your question.

http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/


>
>
> On Thursday, 26 April 2012 at 20:46:41 UTC, 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:
>>
>> - Very fast but no endless callback chains as in node.js
>>   and similar frameworks
>> - Concise API that tries to be as efficient and intuitive
>>   as possible
>> - Built-in HTTP server and client with support for HTTPS,
>>   chunked and compressed transfers, keep-alive connections,
>>   Apache-style logging, a reverse-proxy, url routing and
>>   more
>> - Jade based HTML/XML template system with compile-time
>>   code generation for the fastest dynamic page generation
>>   times possible
>> - Built-in support for MongoDB and Redis databases
>> - WebSocket support
>> - Natural Json and Bson handling
>> - A package manager for seemless use of extension libraries
>>
>> See http://vibed.org/ for more information and some example
>> applications (there are some things in the works such as an
>> etherpad clone and an NNTP server).
>>
>> vibe.d is in a working state and enters its first beta-phase
>> now to stabilize the current feature set. After that, a
>> small list of additional features is planned before the 1.0
>> release.
>>
>> The framework can be downloaded or GIT cloned from
>> http://vibed.org/ and is distributed under the terms of the
>> MIT license.
>>
>> Note that the website including the blog is fully written
>> in vibe and provides the first stress test for the
>> implementation.
>>
>> Regards,
>> Sönke
November 04, 2013
On Monday, 4 November 2013 at 16:40:25 UTC, Alexandre Riveira wrote:
> Hi Sönke,
>
>
> Congratulations for your hard work.
>
>
> One question,
> How do you think your framework running in development mode where a huge amount of models with many business rules exist. A system under development can be slow, like java where a signature change in the method requires reload of the whole application.
>
> Alexandre Riveira

I might recommend to wait a bit before trying it in production until CI suite is figured out (it is work in progress), there are some concerns with stability/regressions right now because it grows just too fast.

Once this stuff is back under control though, there is no reason why it shouldn't scale to complex business logic scenarios. It may require writing own modules for something like XML-based configuration or similar Java-ish stuff as vibe.d itself is more declarative / procedural in style but foundation is pretty solid.

I also recommend asking more specific questions in vibe.d own newsgroup as Sonke pays more attention to it, he is obviously quite a busy guy :)
November 05, 2013
Hi Alexandre,

I'll try to answer as good as I can, please excuse if I got part of your question wrong. So I see two parts that can be slow:

1. The application runtime performance. Due to additional debug checks and less optimization, debug builds will run slower than release builds, but this usually gets important only for very high load scenarios for typical vibe.d/D applications. So this is usually nothing to worry about during development. If, however, a release build is required to get acceptable performance, it can easily double the build time.

2. The edit->compile->run->test cycle during development. This will be similar to Java in that it will usually require the whole application to be rebuilt and restarted. Building a vibe.d application currently takes about 12 s for most applications. It can get much slower, though, if the application makes heavy use of templates or compile-time function execution (this is the case for Diet templates [1], for example).

   Having said that, there are ways to get around this in certain situations. At least on Linux (on DMD 2.064 and up) this is now possible relatively easily using core.runtime.Runtime.loadLibrary. Using that, individual components can be built as small shared libraries and loaded dynamically into the running process. Remedy Entertainment has done something similar before Runtime.loadLibrary was available [2].

Best regards,
Sönke

[1]: http://vibed.org/docs#html-templates
[2]: http://www.youtube.com/watch?v=FKceA691Wcg


Am 04.11.2013 17:40, schrieb Alexandre Riveira:
> Hi Sönke,
>
>
> Congratulations for your hard work.
>
>
> One question,
> How do you think your framework running in development mode where a huge
> amount of models with many business rules exist. A system under
> development can be slow, like java where a signature change in the
> method requires reload of the whole application.
>
> Alexandre Riveira
>
>
> On Thursday, 26 April 2012 at 20:46:41 UTC, 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:
>>
>>  - Very fast but no endless callback chains as in node.js
>>    and similar frameworks
>>  - Concise API that tries to be as efficient and intuitive
>>    as possible
>>  - Built-in HTTP server and client with support for HTTPS,
>>    chunked and compressed transfers, keep-alive connections,
>>    Apache-style logging, a reverse-proxy, url routing and
>>    more
>>  - Jade based HTML/XML template system with compile-time
>>    code generation for the fastest dynamic page generation
>>    times possible
>>  - Built-in support for MongoDB and Redis databases
>>  - WebSocket support
>>  - Natural Json and Bson handling
>>  - A package manager for seemless use of extension libraries
>>
>> See http://vibed.org/ for more information and some example
>> applications (there are some things in the works such as an
>> etherpad clone and an NNTP server).
>>
>> vibe.d is in a working state and enters its first beta-phase
>> now to stabilize the current feature set. After that, a
>> small list of additional features is planned before the 1.0
>> release.
>>
>> The framework can be downloaded or GIT cloned from
>> http://vibed.org/ and is distributed under the terms of the
>> MIT license.
>>
>> Note that the website including the blog is fully written
>> in vibe and provides the first stress test for the
>> implementation.
>>
>> Regards,
>> Sönke
>