https://bugs.freedesktop.org/show_bug.cgi?id=38811
--- Comment #17 from dacm <[email protected]> 2012-04-11 01:01:32 PDT --- (In reply to comment #16) @Björn I certainly apologize for the off-topic nature of my comments above, and particularly the "sour grapes" comment, which I retract as insignificant to the overall situation. Please feel free to delete any of my inputs (here and there) as necessary. That entire diatribe was crafted specifically to pour cold-water on would-be developers as they consider their role in coding a perceived regression of LO Base. But after a full day of reading the mailing lists, I do understand the desperate situation for LO Base. I will not attempt to dispel the reasoning I encountered because the desperation of the situation leaves most reality-checks untenable. Something as glaring as the dying nature of desktop-bound code (C++) relative to rich internet-capable apps (html5, and the predecessors including Java, Flash and Silverlight) is simply not appropriate for LO discussion today. That's quite understandable. For those developers that may be interested in this "easy hack" challenge, it is an unfortunate consequence of a rather limited talent pool, that we now find ourselves begging for relief in the form of a Base regression. We certainly prefer to call it an "enhancement" because it will (I'm convinced) pave the way for necessary bug fixes and even improvements to LO Base over the long haul. Because quite frankly, LO Base has been unable to attract and/or retain coders with the necessary skills to tackle C++ and Java combined with an acute knowledge of databases. That's understandable considering that Base is in the (buggy) shape its in today due to the inability of the original Base (Sun) developers to code, document and properly debug this trio. And perhaps particularly so with respect to an in-process (JVM; embedded mode) Java database engine. Reasonable attempts to rectify the situation have even exacerbated the situation (bugs). So given the realities, it is with grave apprehension as a user and support-volunteer that I grant my own blessings for SQLite, as the default database engine in Base. But only because it has the potential to save Base as a component of LO. I will continue to steer users away from "embedded databases" in production environments in general. And I still believe this dumbed-down, programmer's engine is unworthy of a modern, end-user, front-end like Base -- such that LO would be better-off disabling the 'embedded database' option with Base than to embrace such functional regression. But I must admit, the average user will never even use Base without a default (bundled) engine, and perhaps even an all-in-one .odb database option for smaller mail-merge type projects. Eventually, I think it would be advantageous to offer a portable 'split' file configuration in the name of stability, because single-file stability is an issue even with the vast resources of MS Access 2010 -- which is replete with official language warning about the stability of a single-file database -- so much so that it sports a feature to 'split' the components into separate front-end and back-end files "for proper stability." Despite the unbelievable ignorance I've encountered today in the LO mailing lists among devs, designers, documenters and steering-committee leadership with respect to the presumed adequacy of SQLite relative to HSQLDB 2.x, I do agree that SQLite is a necessary evil in the future of LO Base. So I respectfully join Björn and the LO team in the plea for code as necessary to integrate SQLite as a default Base engine. The future of LO Base "unfortunately" rests in your hands. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. _______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
