Right after allocators: containers or database connectivity?

[Charles Hixson via Digitalmars-d]

On 06/09/2015 10:56 AM, luminousone via Digitalmars-d wrote:
> On Tuesday, 9 June 2015 at 17:05:19 UTC, Andrei Alexandrescu wrote:
>> My work on allocators takes the last turn before the straight line. 
>> I've arranged with Dicebot to overlap the review period with 
>> finalizing details so I can act on feedback quickly.
>>
>> After that I'm ready for some major library work, and I had two 
>> things in mind.
>>
>> One would be a good pass of std.container, in particular (a) a design 
>> review with the DbI glasses on; (b) better documentation - sadly it 
>> seems to me so inadequate as to make containers themselves unusable; 
>> (c) investigate use of UFCS - std.container's design predates UFCS 
>> yet is a perfect fit for it, and most likely other cool language 
>> improvements we've added since.
>>
>> The other would be database connectivity. Erik Smith has shown some 
>> cool ideas at DConf, and I encourage him to continue working on them, 
>> but it seems to me this is an area where more angles mean more 
>> connectivity options.
>>
>> For database connectivity I'm thinking of using ODBC. What I see is 
>> that on all major platforms, vendors offer mature, good quality ODBC 
>> drivers, and most programs that have anything to do with databases 
>> offer ODBC connectivity. So connecting with ODBC means the individual 
>> database drivers are already there; no need to waste effort on 
>> creating drivers for each (or asking vendors to, which we can't afford).
>>
>> So I gave myself ten minutes the other night just before I went to 
>> sleep to see if I can get an ODBC rig on my OSX machine starting from 
>> absolutely nothing. I got http://www.odbcmanager.net but then got 
>> confused about where to find some dumb driver (text, csv) and gave up.
>>
>> Last night I gave myself another ten minutes, and lo and behold I got 
>> up and running. Got a demo CSV driver from 
>> http://www.actualtech.com/product_access.php (which also supports 
>> Access and others). Then I headed to 
>> http://www.easysoft.com/developer/languages/c/odbc_tutorial.html and 
>> was able to run a simple ODBC application that lists the available 
>> drivers. Nice!
>>
>> It's trivial work to convert the C headers to D declarations. Then 
>> it's straight library design to offer convenient libraries on top of 
>> the comprehensive but pedestrian ODBC C API. Then, voilà - we'll have 
>> database connectivity for all databases out there!
>>
>> Please help me choose what to work on next.
>>
>>
>> Andrei
>
> I would think a good database lib would depend on a good container 
> lib, So IMO, the order is self evident.
>
> 1000+ to containers.
>
I'd say what it depends on is good serialization.  If you extend 
containers to include disk based B+Trees then I'd agree with you, 
otherwise not.