View mode: basic / threaded / horizontal-split · Log in · Help
May 03, 2012
Re: Introducing vibe.d! SOAP .. REST?
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
Re: Introducing vibe.d!
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
Re: Introducing vibe.d!
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
Re: Introducing vibe.d!
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
Re: Introducing vibe.d!
How do a manual install on linux ?
I am a fedora user they are no specialized or common install
documentation!
May 19, 2012
Re: Introducing vibe.d!
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
Re: Introducing vibe.d!
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
Re: Introducing vibe.d!
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
Re: Introducing vibe.d!
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
Re: Introducing vibe.d!
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
>
7 8 9 10 11 12
Top | Discussion index | About this forum | D home