Hi Josh, > Of course, now that Sun is the official lead sponsor of the Derby/JavaDB > project, they want to use it for OOo-Base. I've been asked to raise the > issue here, namely: > > "What would it take to get OOo to switch from HSQLDB to JavaDB?" > > Significant assistance from the Sun Derby team, including migration and > tools, > is not at all out of the question. So what are the reasons not to switch? > What's the costs?
In short: Credits in the user base. In long, it's more complex than this. Of course. One thing I mentioned here quite some time ago, when I was asked what's the future of HSQLDB in OOo, is the following: I don't have any intention to ship OOo with a different database engine every second release. I consider reliability - people should know what to expect from their product - a major item. It's not that we do not have experience with this kind of thing ... When I started working for StarOffice, it had a third party database engine licensed from a company whose name just slippes my mind :). Two releases later, we gave it up (for good reasons) and shipped with Adabas D. Currently, we're shipping SO with Adabas D and HSQLDB. That kind of thing - the constant need for migration, the constant adaptions to quirks of the "current engine" - is no fun at all. And, worse, it doesn't give the user the feeling of reliability, because with every change, we start over from scratch. All that said, I, as project owner of Base, don't have any intention to switch from HSQLDB to another engine. On the short term, I cannot rule out that we at least ship OOo with Derby/JavaDB as alternative. On the medium term, I cannot rule out that there's an decision to use Derby/JavaDB as default engine. But at the very moment, with the very limited developer resources we have in the Base project, I don't think it's a good idea to spend those resources to integrate "Yet Another Database Engine" (no offense intended at all), just to have basically the same situation / feature set as before. Of course, if somebody else volunteers to spend resources for this project, we certainly won't block this (as you can see in [1]). What I *would* try to block is making Derby/JavaDB the default engine by tomorrow, for the reasons mentioned above. The fact that I work for Sun, and Sun is the main sponsor of the Derby project, doesn't change this. It just means that it's possible that I'll be overruled Sun-internally ;) Okay, so far for the "reasons not to switch", with some small digressions :) For the costs: Certainly some implementations have to be done on Derby side, whose costs I cannot judge, but I am sure they'd be willing to provide all needed assistance. On OOo side, writing a driver for an "embedded Derby" would take guestimated 2 man months for a halfway experienced developer. Plus, if we're really talking about a switch and not just an alternative, the political decision to do so. As said, I'd oppose such a decision, until convinced or overruled. Does this answer your questions? Ciao Frank [1]http://wiki.services.openoffice.org/mwiki/index.php?title=SummerOfCode2006#Embed_Derby_into_OpenOffice.org_databases --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
