www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Libs, my projects

reply Ant <Ant_member pathlink.com> writes:
I have some additions to my lib projects
(to release very soon):
- updated libpq postgreSQL wrapper (dpq)
- sqlite3 wrapper 
- common interface for dpq and sliqte (DDBC)
- cliente for DDBC
- dool (d object oriente runtime lib)
- DUI now depends on dool

what's the importance of keeping these things independent?

I believe my projects are mostly ignored by the community so
I'm thinking of integrating every thing into dool and DUI
keeping just those two libs.
I would do that for ease of maintenance and distribution.
These libs would be compiled including or not external
dependencies (sqlite3, postgreSQL and others on the future)
I'll keep dool separated from DUI because, because...(?)

if you don't care just don't reply.
if no strong arguments against integration are presented in
a couple of days I'll just go ahead (this time just bundle 
the SQL things into dool and the client into duiextra or
something like that)

http://dool.sourceforge.net
http://dpq.sourceforge.net
http://dui.sourceforge.net
http://leds.sourceforge.net

Ant
Sep 27 2004
next sibling parent reply pragma <pragma_member pathlink.com> writes:
If its easier to maintain as one or two libraries, I say "go for it".  The worst
that can happen is if someone has a requirement that you break things back out
(unlikely).

FYI, I am shopping around for future DB components to use in DSP once it matures
to that point. ;)

In article <cj95rs$s51$1 digitaldaemon.com>, Ant says...

I have some additions to my lib projects
(to release very soon):
- updated libpq postgreSQL wrapper (dpq)
- sqlite3 wrapper 
- common interface for dpq and sliqte (DDBC)
- cliente for DDBC
- dool (d object oriente runtime lib)
- DUI now depends on dool

what's the importance of keeping these things independent?

I believe my projects are mostly ignored by the community so
I'm thinking of integrating every thing into dool and DUI
keeping just those two libs.
I would do that for ease of maintenance and distribution.
These libs would be compiled including or not external
dependencies (sqlite3, postgreSQL and others on the future)
I'll keep dool separated from DUI because, because...(?)

if you don't care just don't reply.
if no strong arguments against integration are presented in
a couple of days I'll just go ahead (this time just bundle 
the SQL things into dool and the client into duiextra or
something like that)

http://dool.sourceforge.net
http://dpq.sourceforge.net
http://dui.sourceforge.net
http://leds.sourceforge.net

Ant


version(DNG) pragma(EricAnderton,"yahoo");
Sep 27 2004
parent Ant <Ant_member pathlink.com> writes:
In article <cj9738$t01$1 digitaldaemon.com>, pragma says...

If its easier to maintain as one or two libraries, I say "go for it".  The worst
that can happen is if someone has a requirement that you break things back out
(unlikely).

FYI, I am shopping around for future DB components to use in DSP once it matures
to that point. ;)


DDBC defines the Connection, Statement, ResultSet model found on
other database drivers.
also supplies Tuple and Meta Tuple information (I kinda of like it).

dpq still contains the the d wrappers to the specific libpc API.


In article <cj95rs$s51$1 digitaldaemon.com>, Ant says...

I have some additions to my lib projects
(to release very soon):
- updated libpq postgreSQL wrapper (dpq)
- sqlite3 wrapper 
- common interface for dpq and sliqte (DDBC)
- cliente for DDBC
- dool (d object oriente runtime lib)
- DUI now depends on dool

what's the importance of keeping these things independent?

I believe my projects are mostly ignored by the community so
I'm thinking of integrating every thing into dool and DUI
keeping just those two libs.
I would do that for ease of maintenance and distribution.
These libs would be compiled including or not external
dependencies (sqlite3, postgreSQL and others on the future)
I'll keep dool separated from DUI because, because...(?)

if you don't care just don't reply.
if no strong arguments against integration are presented in
a couple of days I'll just go ahead (this time just bundle 
the SQL things into dool and the client into duiextra or
something like that)

http://dool.sourceforge.net
http://dpq.sourceforge.net
http://dui.sourceforge.net
http://leds.sourceforge.net

Ant


version(DNG) pragma(EricAnderton,"yahoo");
Sep 27 2004
prev sibling parent reply Charles Hixson <charleshixsn earthlink.net> writes:
Ant wrote:

 I have some additions to my lib projects
 (to release very soon):
 - updated libpq postgreSQL wrapper (dpq)
 - sqlite3 wrapper 
 - common interface for dpq and sliqte (DDBC)
 - cliente for DDBC
 - dool (d object oriente runtime lib)
 - DUI now depends on dool
 
 what's the importance of keeping these things independent?
 
 I believe my projects are mostly ignored by the community so
 I'm thinking of integrating every thing into dool and DUI
 keeping just those two libs.
 I would do that for ease of maintenance and distribution.
 These libs would be compiled including or not external
 dependencies (sqlite3, postgreSQL and others on the future)
 I'll keep dool separated from DUI because, because...(?)
 
 if you don't care just don't reply.
 if no strong arguments against integration are presented in
 a couple of days I'll just go ahead (this time just bundle 
 the SQL things into dool and the client into duiextra or
 something like that)
 
 http://dool.sourceforge.net
 http://dpq.sourceforge.net
 http://dui.sourceforge.net
 http://leds.sourceforge.net
 
 Ant
 
 


I don't know dool...(no files release on sourceforge, sketchy 
description, makes it difficult to evaluate).  OTOH, I'm quite 
interested in the sqlite3 wrapper.  Only problem is that sqlite2 is 
what I have installed, and it'll probably stay that way until after 
I upgrade to the 2.6 kernel.  Then I'll see what I need to upgrade 
to install sqlite3.  (It doesn't seem to be a part of the Debian 
packages.)

Currently I'm building a package in Ruby using Sqlite, but I have 
the intention of moving it to D when it's more complete.
Sep 27 2004
parent reply Ant <Ant_member pathlink.com> writes:
In article <cj9rg9$19mm$1 digitaldaemon.com>, Charles Hixson says...

Ant wrote:

 I have some additions to my lib projects
 
 


I don't know dool...(no files release on sourceforge, sketchy 
description, makes it difficult to evaluate).


I forgot that, see the manifest at:
http://sourceforge.net/forum/forum.php?thread_id=1121037&forum_id=394961


  OTOH, I'm quite 
interested in the sqlite3 wrapper.


If you want a thin wrapper try Vathix's.
The thing is very simple.
Mine completly hides the sqlite3 C API.


 Only problem is that sqlite2 is 
what I have installed, and it'll probably stay that way until after 
I upgrade to the 2.6 kernel.


You should check first,
but I'm prety sure you can have both versions installed.


  Then I'll see what I need to upgrade 
to install sqlite3.  (It doesn't seem to be a part of the Debian 
packages.)

Currently I'm building a package in Ruby using Sqlite, but I have 
the intention of moving it to D when it's more complete.


ah! double the work ;)

Ant
Sep 27 2004
parent reply Gold Dragon <dragonwing dragonu.net> writes:
 You should check first,
 but I'm prety sure you can have both versions installed.


According to the documentation you can but you have to watch for the linkage
between the version 
numbers... or something. Read docs, they have more and better information... I
don't think I'm 
talking to Ant but the Other Guy(tm).

Jacob Santos
Sep 27 2004
parent reply Charles Hixson <charleshixsn earthlink.net> writes:
Gold Dragon wrote:

 You should check first,
 but I'm prety sure you can have both versions installed.


 
 
 According to the documentation you can but you have to watch for the 
 linkage between the version numbers... or something. Read docs, they 
 have more and better information... I don't think I'm talking to Ant but 
 the Other Guy(tm).
 
 Jacob Santos


Thanks, but I want my attention focused elsewhere.  And by the time 
I start worrying about efficiency we'll probably be as Sqlite4. 
(OTOH, if the thing by Vathix looks good, perhaps I'll start 
switching immediately.)
Sep 28 2004
parent Charles Hixson <charleshixsn earthlink.net> writes:
Charles Hixson wrote:

 ...hanks, but I want my attention focused elsewhere.  And by the time I 
 start worrying about efficiency we'll probably be as Sqlite4. (OTOH, if 
 the thing by Vathix looks good, perhaps I'll start switching immediately.)


Mmph.  It turns out that was the Sqlite3 binding I was thinking of. 
  So I'll wait-a-bit.
Sep 28 2004