I'm in the process of moving the DBI source to Subversion hosted by perl.org. I think that would be a good home for DBDI as well.
Excellent.
1. A clean stable application API as close to the DBI as practical. That means:
This is something I am trying hard to get to and I will probably focus a lot of attention here.
Method names, parameters, return values as per DBI
Opaque handles (I think ".sym pmc dbh" will work rather than a named reference type I suggested earlier)
Thankfully this is relatively easy, and you are correct it should work just by changing the names , I will confirm this later.
Method calls (though if IMCC will get a clean syntax for them soon
it maybe best to wait and avoid the messy name mangling meanwhile.)
I would like to avoid name mangling to just to achieve sudo objects. I would rather try and get a perfect API with a severly hacked back end and then as we get objects I can add them as I go along. If the API is correct and people avoid making calls behind it then we should be pretty watertight.
Get as close to my "design notes" (reposted this morning) as possible.
eg set_err(), err(), errstr(), new_child() get_row_array() etc
This is an area that will involve some work. At the moment I am building up structures in a hierarchal nature. I have only got as far as
.sym dbh_container PerlHash
dbh_container['DBD::_::db']
This hols all the dbh objects which at this point are "PerlHash"
sth_container['DBD::_::st']
Each dbh has one ['DBD::_::st'] which contains as many sth handles as we want. sth is another PerlHash.
All this will become apparrent when I release the next example. This all came about trying to get multiple handles working although it has not been fully tested it is working for single handles ;-)
I now need to add the higher object structure ie
DBD:::_::common DBD:::_::dr
2. Make example less hard coded:
take dsn, user, password from command line
loop, asking for sql then execute, fetch, loop.
There are areas that concern me at the back end because they are hard coded due to not having runtime loading of the driver byt this is unavoidable. I will change them to more versatile methods where I can.
3. Some docs for "How to get started with Parrot and IMCC" that just lists pointers to other docs plus a walk-through to get setup: fetch parrot from <url> unpack, cd, configure, build, install these files are the dbdi source ... run this command to execute the dbdi example So newcomers can hit the ground running.
4. An NCI interface for mysql would greatly increase the potential early userbase.
I am going to get some of this stuff in some sort of priority order. Doing the MySQL driver will eat a fair bit of my time but I am more than happy to do it if it gets us a lot more users. The docs would take me a day to get something working which is probably the biggest win for the least effort.
5. Get into subversion as soon as it's available
I've asked Ask & Rob at perl.org to set it up.
Anyone wanting access should start by geting an account at auth.perl.org
This will speed things up a bit.
I will post the new example code for you all to take a look at. I am probably not going to be able to respond to any more emails until Monday. Which is another good reason to get this into subversion asap.
Harry
