ab,
You get a big
Hi from me too. For the moment I'm a liitle busy with other stuff too.
gto,
My weekend will be a little wild too. I'll be responsible for the Red Cross people at the following 'music' event :
EuroMillions Groove City. So no coding time for me too.
ab,
Please, make setting up the zeoslib test suite your first job this weekend. Use SQLite or eventually Oracle. Don't start with MSAccess, I think it'll be a nightmare. If you can get the automated build system working, please do so. You only need apache Ant to use it, no more dependencies.
This topic is quite recent:
http://zeos.firmos.at/viewtopic.php?t=2951
If you get the suite running and more than 80% of the tests ran correctly, save the log files of 1 run as your baseline (I call this the 'reflogs'). That way you can compare the effect of your changes on the test suite using software like winmerge.
Then, I think the dbc data storage will be your next target, doing the necessary changes to use the right data storage format. (If I remember correctly this is mainly situated in the ZDbcCache unit, but that I might be completely wrong about that)
Normally this change can be done without affecting the current functionality of zeoslib, as all interaction with the cache should happen using interface methods.
After that we'll have to talk about the way we handle plain database connection (= at dbc and plain level). Will we provide a way to send a prefered charset to the database driver for the connection or will zeoslib force each driver to use only one charset? The latter solution wll be easiest to implement, I think. But I'm not sure if that's the best solution in all cases.
When allowing the users to choose the connection charset, would that influence the internal cache storage format needed?
Then the next thing to look at probably is the dbc resultset object and methods. And probably rework data fetching for the SQLite database driver to allow fetching non-utf8 encoded data from that database WITHOUT affecting the way data is fetched from other database drivers.
By that time we should feel comfortable enough to look at DbcStatements and sqlstring+(blob?) parameter handling, I hope.
Practically : I suppose you'd like to get SVN update rights soon. If patches come the way gto and me like them, this can be arranged. However, it's not something we can administer ourselves as it's done by the firm sponsoring our repository server. So I prefer to use a short 'trial' period to see how things work out.
During that period you'll have to send the changes in relatively small portions as SVN diffs (preferably use the create patch feature of TortoiseSVN).
Just send them to a (new) specialised thread on this or the user patches forum.
Please try to organise the work step by step.
For instance when using my proposal in this post : first the patch for the internal cache (including eventual changes to 'core' to support this change). The gto, andrevanzuydam or I can test-run-and-apply this patch. And then we can move on.
If we don't work this way we'll end up with one huge proposal from one independent developer and applying that will become a huge risk. (Practical and functional)
Concerning the branching/merge policy I use:
- testing branch can accept all patches that do not terribly break the test suite. Please provide all patches using this branch
- after at least a week the changes that do not break the trunk test suite at all can be merged to trunk. So if changes to testing branch causes some known small issues they'll have to be fixed before merging to trunk.
Do you think we can worjk together like this?
Mark
BTW, don't hesitate to contact me using one of the means you can find in my profile. You can use these communication means any time I'm online, I'll honestly tell you when it doesn't really fit in my time scheme.
Mark
