On 02/13/2016 09:33 PM, Eugene Wissner wrote:
> On Saturday, 13 February 2016 at 15:20:26 UTC, Suliman wrote:
>>
>> But we already have ddbc, that work pretty fine. Its better to force developing of it
> 
> I also looked into ddbc  before. And it is a great thing since it is similar to the well known jdbc. I didn't like that it just wraps C-functions to access the postgresql. But I don't see the vibe.d incompatibility as a problem. Would be really greate to merge ddbc and ddb ;)

It isn't specifically vibe.d incompatibility that is a problem but general lack of support of async I/O model which is a showstopper for using such solution in any serious network application. Ideally ddb should be built on top of ddbc wrapping it into fiber-friendly async API but I don't know if this is possible with ddbc design.

On 2016-02-14 00:32, Dicebot wrote:

> Ideally ddb should be built on top of ddbc wrapping it into fiber-friendly async API
> but I don't know if this is possible with ddbc design.

It looks like libpg has support for asynchronous calls [1] but ddbc does not use them. Also, although libpg provides asynchronous calls I'm not sure if that automatically means it will be compatible with the IO model used by vibe.

It seems both ddb and ddbc had the same idea, building a library accessing databases independently of the kind of database. The difference is that ddb does not seem to have the abstraction making it database independent and only works for Postgres. ddbc on the other hand does support multiple databases and have the abstraction layer. So at this point ddb is basically a Postgres driver and nothing more.

I like that ddb is completely written in D and doesn't depend on any C libraries. It's also compatible with the IO model of vibe.

Ideally a database library would consist separate projects for the different database drivers. These would be fully usable on their own. The database library would build a database independent layer on top of the drivers. Everything should be compatible with the IO model of vibe.

I would go with ddb and mysql-native for the drivers.

[1] http://www.postgresql.org/docs/current/static/libpq-async.html

-- 
/Jacob Carlborg

On 2016-02-13 14:11, Eugene Wissner wrote:

> Indeed. I have a fresh organization where I maintain D code:
> https://github.com/caraus-ecms. I could move it there and add pszturmaj
> to the organization.

I don't see anything with the things you don't like about vibe.d going against vibe.d. It's just the default settings/choices that don't match what you want/need.

"vibe.d is a framework to develop servers, network applications, it isn't really something you would usually use to develop a simple webpage or a blog or a forum."

There are some abstractions on top of vibe.d [1] [2].

"I don't like Diet-Jade templates. I prefer templating engines like Mustache or Smarty."

There are several Mustache packages for available through Dub [3] [4] [5].

"I don't like the choice of databases. Ok, I actually could write a driver for another database... I would go for PostgreSQL for the first time and it is still unsupported by default."

Ddb, you already know about that one.

"I want to learn D. PHP or Java may have too many frameworks, but it is still good to have a few of them, so people can choose what they like more."

If you don't like any of the packages you can write your own on top of vibe.d.

What I mean is that you don't need to start from scratch and write a completely new web framework.

[1] http://code.dlang.org/packages/action-pack
[2] http://code.dlang.org/packages/zeal

[3] http://code.dlang.org/packages/semitwistweb
[4] http://code.dlang.org/packages/mustache-d
[5] http://code.dlang.org/packages/jax

-- 
/Jacob Carlborg

> Ideally a database library would consist separate projects for the different database drivers. These would be fully usable on their own. The database library would build a database independent layer on top of the drivers. Everything should be compatible with the IO model of vibe.

+1. It would be really great.

Does anybody know something about dpq2? It doesn't use C-interface directly, but uses libpq's shared library (.so, .dll or .lib). It claims to support async queries and is most actively maintained in this time as I see. And it cares only about PostgreSQL.

Am 14.02.2016 um 13:01 schrieb Jacob Carlborg:
> On 2016-02-13 14:11, Eugene Wissner wrote:
>
>> Indeed. I have a fresh organization where I maintain D code:
>> https://github.com/caraus-ecms. I could move it there and add pszturmaj
>> to the organization.
>
> I don't see anything with the things you don't like about vibe.d going
> against vibe.d. It's just the default settings/choices that don't match
> what you want/need.
>
> "vibe.d is a framework to develop servers, network applications, it
> isn't really something you would usually use to develop a simple webpage
> or a blog or a forum."
>
> There are some abstractions on top of vibe.d [1] [2].

The approach of the vibe.web package is also already very similar to that IndexController mentioned in the other post.

On Saturday, 13 February 2016 at 19:06:46 UTC, Eugene Wissner wrote:
> On Saturday, 13 February 2016 at 14:52:46 UTC, Adil Baig wrote:
>> Hey Eugene,
>>
>> Caraus seems like an interesting project. How do you plan to build it out and differentiate it from vibe.d?
>
>
> Difficult to explain it in a few sentences in a foreign language, but I'll try. Just don't hesitate to ask if you have any questions. I'm also not very familiar with vibe.d, I've just seen a few examples and read about it a bit; so Sönke should excuse or correct me if I say nonsense :).
>
> It should be a framework for easy building and maintaining of websites. The applications built on it would follow MVC (or MVC-like) pattern by default, but since the framework is thought as a set of reusable components/modules it should be possible to use it for everything else like micro-webframework for small projects with custom structure. The whole framework should ship an abstraction over HTTP(S), mail sending (sendmail, smtp), session handling with a possibility to implement an own storage (file system, redis, memcached, PostgreSQL...), dependency injection, router and so on.
>
> It is a very common description. Now I make a few examples showing what I think the framework should be able to do.
>
> 1) Creating a website should be as simple as creating a Controller and a router configuration (YAML  or database for example), that assigns some route to this controller. Think of something like this:
>
> class IndexController
> {
>   indexAction(Request request)
>   {
>     int contentId = this.getDatabase().getContentModel().getPageById(5);
>
>     this.render("myTemplate.tpl", ["content": contentId]);
>   }
> }
>
> 2) Form handling. You create a register form. So you create a class User:
> class User
> {
>   int username;
>   string password;
> }
>
> and that class with some additional information should be rendered to a web form. There are should be also routins to help to verify the form (helpers for checking for email, length of the input, phone number) and persist it to a database. Whereby I don't think on ORM here, I'm not a big fan of ORMs. For my projects I would implement a rich domain model with domain objects, mappers... But it should be possible to use ORM as well if this is available. Dependency Injection would make such freedom possible. Btw. I think I won't write a DIc, https://github.com/mbierlee/poodinis looks very promissing for me. I would use any tools that meet requirements.
>
> So it should help web developers in their daily job and should make the web development pleasant.
> It doesn't mean that I implement 10 session handlers from the beginning. I will slowly implement things that I need for my projects and will accept contributions if there are some contributers one day.
> And I can't promise that everything will be ready tomorrow. It is very time consuming. But I got a new project last week that may grow in the future. So I will begin to use these tools for my work (I'm pretty free what I'm writing in and how I do it).
>
> It can overlap with vibe.d here and there, but I think it is more a continuation of vibe.d's http submodule. There were already few attempts to create a similar framework on top of vibe.d, see: https://github.com/CarbonComputed/carb.d or https://github.com/Skadi-d/Skadi.d for example. But I want to make it independent of the underlying platform (vibe.d, SCGI, FastCGI).
> So far....

my five cents on that topic...

@Eugene:
From my point of view, it would be great if you could bring in all your ideas, wishes, changes, additions and new stuff into vibe_d and help to grow and extend it and make it more usable...

Don't get me wrong, I thinks it's great if developers have various choices in general to pick from, but especially in Dlang "core tools" some of the existing stuff needs more contributors/help... like vibe_d, dub (both from Sönke & team) dfmt, ...

You and Sönke share the same native language (German) and also the same time zone (Munich/Berlin)... and as it seems also the same interest in "Web stuff/Frameworks", right? It shouldn't be that difficult for you guys to alighn and team-up to build an even better "Dlang Web tools/Framework development team"...

>
> my five cents on that topic...
>
> @Eugene:
> From my point of view, it would be great if you could bring in all your ideas, wishes, changes, additions and new stuff into vibe_d and help to grow and extend it and make it more usable...
>
> Don't get me wrong, I thinks it's great if developers have various choices in general to pick from, but especially in Dlang "core tools" some of the existing stuff needs more contributors/help... like vibe_d, dub (both from Sönke & team) dfmt, ...
>
> You and Sönke share the same native language (German) and also the same time zone (Munich/Berlin)... and as it seems also the same interest in "Web stuff/Frameworks", right? It shouldn't be that difficult for you guys to alighn and team-up to build an even better "Dlang Web tools/Framework development team"...

My native language is Russian, but my German is anyway better than my English, it's true :)

Yes, I actually understand your point. I thought about it already and it could be really more productive. I think I have to look in vibe more closely. Maybe I'll just look into open issues on github, maybe I'll be able to find a few easy issues, I could try to fix - it could be the best way for me to get know vibe.d internally better.

On 2016-02-14 12:48, Jacob Carlborg wrote:
> It seems both ddb and ddbc had the same idea, building a library
> accessing databases independently of the kind of database. The
> difference is that ddb does not seem to have the abstraction making it
> database independent and only works for Postgres. ddbc on the other hand
> does support multiple databases and have the abstraction layer. So at
> this point ddb is basically a Postgres driver and nothing more.

ddb was written with multiple databases in mind, mostly postgres, mysql and sqlite. db.d (DBRow definition) is database independent. postgres.d contains PGConnection, PGCommand, etc. Other backends should provide their own classes like MySqlConnection, MySqlCommand and so on. Then it's trivial to add an abstraction layer that chooses between different backends depending on the connection string for example.

Regarding ddb maintainability, thank you for your interest, I can add you both (Jacob and Eugene) to my repository as collaborators, you will have full access to repo, pull requests and issues. If I will ever need ddb in some of my project I would still have access to my repo to make some changes. If the project will grow bigger than expected we could move it to the new repo later. Is that okay for you?

On Sunday, 14 February 2016 at 16:53:31 UTC, Piotr Szturmaj wrote:
> On 2016-02-14 12:48, Jacob Carlborg wrote:
>> It seems both ddb and ddbc had the same idea, building a library
>> accessing databases independently of the kind of database. The
>> difference is that ddb does not seem to have the abstraction making it
>> database independent and only works for Postgres. ddbc on the other hand
>> does support multiple databases and have the abstraction layer. So at
>> this point ddb is basically a Postgres driver and nothing more.
>
> ddb was written with multiple databases in mind, mostly postgres, mysql and sqlite. db.d (DBRow definition) is database independent. postgres.d contains PGConnection, PGCommand, etc. Other backends should provide their own classes like MySqlConnection, MySqlCommand and so on. Then it's trivial to add an abstraction layer that chooses between different backends depending on the connection string for example.
>
> Regarding ddb maintainability, thank you for your interest, I can add you both (Jacob and Eugene) to my repository as collaborators, you will have full access to repo, pull requests and issues. If I will ever need ddb in some of my project I would still have access to my repo to make some changes. If the project will grow bigger than expected we could move it to the new repo later. Is that okay for you?

yes, it is for sure ok for me. It can be a good start.

I think may be we should discuss if we can/should change something in ddb. I think there were some interesting and promising ideas in this discussion. Maybe split the PostgreSQL driver and develop it seperately and use an interface more similar to JDBC. Maybe some kind of coworking with ddbc is possible to get more developers together; maybe Suliman has some thoughts on it.

On Sunday, 14 February 2016 at 19:48:34 UTC, Eugene Wissner wrote:
> On Sunday, 14 February 2016 at 16:53:31 UTC, Piotr Szturmaj wrote:
>> On 2016-02-14 12:48, Jacob Carlborg wrote:
>>> It seems both ddb and ddbc had the same idea, building a library
>>> accessing databases independently of the kind of database. The
>>> difference is that ddb does not seem to have the abstraction making it
>>> database independent and only works for Postgres. ddbc on the other hand
>>> does support multiple databases and have the abstraction layer. So at
>>> this point ddb is basically a Postgres driver and nothing more.
>>
>> ddb was written with multiple databases in mind, mostly postgres, mysql and sqlite. db.d (DBRow definition) is database independent. postgres.d contains PGConnection, PGCommand, etc. Other backends should provide their own classes like MySqlConnection, MySqlCommand and so on. Then it's trivial to add an abstraction layer that chooses between different backends depending on the connection string for example.
>>
>> Regarding ddb maintainability, thank you for your interest, I can add you both (Jacob and Eugene) to my repository as collaborators, you will have full access to repo, pull requests and issues. If I will ever need ddb in some of my project I would still have access to my repo to make some changes. If the project will grow bigger than expected we could move it to the new repo later. Is that okay for you?
>
> yes, it is for sure ok for me. It can be a good start.
>
> I think may be we should discuss if we can/should change something in ddb. I think there were some interesting and promising ideas in this discussion. Maybe split the PostgreSQL driver and develop it seperately and use an interface more similar to JDBC. Maybe some kind of coworking with ddbc is possible to get more developers together; maybe Suliman has some thoughts on it.

I like idea to have one good driver instead of two of not finished, and would like that it ships as vibe-d module. For my regret I have not enough so experience to help with developing. But if you will decide to collaborate with ddbc developer (he is also russian-speaker) it will be very cool.