Hi,
Jonathon Blake wrote:
with 2.0 beta almost out of the door,
Is this the reason the 2.0 beta was not released in November, as the _original_, not updated schedule proposed? The updated schedule slipped the date to December, then January, and now early summer.
IIRC the reason to slip the beta was that the quality was generally insufficient for a beta. I don
HSQLDB is the only remaining viable solution, at least for 2.0.
Why does this remind me of _The Mythical Man Month_?
In what respect? And what are your alternative viable solutions for 2.0?
all this talk should have taken place one year ago or earlier, now,
Some of it did take place back then.
Yes. And the dba developers clearly explain why they chose HSQLDB over SQLite then - of course based on what they knew at the time.
I don't know if the financial aspects were discussed, but I doubt anybody expected OOo to be more or less held hostage to the developers of the database that was selected.
I don't think anybody expected that we would have to resort to this call for donations. From Frank's request I take it that the effort needed to finish the HSQLDB integration exceeded the initial estimations and that this in turn exceeds the amount of unpaid effort the HSQLDB maintainers are able to put into this.
As to being held hostages: HSQLDB is open source. So if you some developers to spare you could put them to work on the code instead. But it'll take them some time to get up to speed, so this would take longer and be less efficient than getting the maintainers to do the work for us. The same would have been true for any project we chose. Had we opted for SQLite, we would be 'hostages' of the SQLite maintainers just as much (or as little).
I still don't see any _technical_merits that favor HSQLDB over SQLite. More to the point, there are technical reasons to use SQLite.
The technical reasons I see are that there was (at the time when the decision was taken) no sdbc driver for SQLite and the OBDC driver was insufficient. While there now appears to be such a driver, I haven't heard that it is anywhere near production quality.
There is _nothing_ on the OOo that specifically states why HSQLDB is technically better than SQLite.
I don't think it is necessarily considered technically better. But HSQLDB was considered to be good enough - with a limited amount of enhancement work. For HSQLDB there probably also would have been the necessity of some enhancements *plus* the need to develop a driver. Currently we discover that we don't even have the resources to finish the (smaller) amount of work needed for integration HSQLDB unless we can get more contributions from the HSQLDB maintainers than they can provide for free. What makes you think that we would have had enough developer resources to finish the (larger) effort to integrate SQLite instead in the same timeframe?
So maybe there are no technical reasons to choose HSQLDB over SQLite if you have unlimited people or time. But I do think that the desire to have a good-enough solution within the 2.0 timeframe is a very valid reason.
like it or not, we have to live with it,
Add the SQLite C Code. Add the OOo interface for SQLite --- in theory, all that requires is
creating a new UI, using _existing_ calls within OOo.
So you do have a production quality driver for SDBC that works flawlessly with the OOo sdbc framework?
The latter is part that will require the most time.
The problem is that to have this in OOo 2.0 all this should have existed at least in alpha quality 6 months ago - with sufficient development resources committed to bring it to Beta quality by now.
Six systems that had 1.x GB processors, 2 GB RAM and 250+ GB drive space.
Where does this line come from?
Ciao, Joerg
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
