SQLite Bindings

[Jonas Drewsen]

On 14/03/11 04.33, dsimcha wrote:
> On 3/13/2011 5:56 PM, Jonas Drewsen wrote:
>> It's a great idea. But I think there need to be some kind of janitor for
>> the 'etc' modules so that it does not end up as a new dsource collection
>> of many unmaintained, some dead and a few live projects.
>
> I don't see why this is a concern. This is what I have in mind:
>
> 1. There are a lot of good C libraries out there, some of which are
> generally useful enough to be in a standard library and are license
> compatible with Phobos. My thoughts are that we would only include very
> stable C libs that are unlikely to require significant maintenance
> effort. My personal short list is libcurl (looks like it's already
> happening), SQLite, libpng, and, if we can get a binary attribution
> clause waiver, libbzip2.
>
> 2. The hassle of compiling the C code, translating the header, etc. is a
> significant and annoying transaction cost that probably deters people
> from writing good D wrappers and leads to lots of duplication of effort
> among people who are kinda sorta considering writing one.
>
> 3. Even if someone doesn't intend to write a wrapper initially, they may
> start using the C API directly and eventually end up refactoring out a
> good wrapper from the project that uses the C API. This is more likely
> if the C API is already there, waiting to be used.
>
> 4. Even if a D wrapper is not written for a long time, having the plain
> C API available for those that want to use it is substantially better
> than nothing, and the C API will not go away once a D wrapper is written.

Maybe I'm too concerned yes. Would just hate to have new users using bit 
rotten code because no one suddently cared about a specific module for a 
while.

But maybe curl,png,sqlite etc. libraries are used enough so that someone 
always cares keeping it up-to-dat and this does not become a problem. 
Lets see :)

/Jonas