Hi :) People have said that in order to fix the current bugs in Base there is going to involve improving and adding to the java that is used. This is going to be quite confusing and messy because to take Base forwards we need to reduce the amount of java overall.
If we could get enough devs involved all-at-once then we might be able to get rid of java, shift to something to replace it and check which bug-reports are still in need of fixing. However, it's not likely to work out that way! With a small number of devs gradually joining the project one at a time a lot of the work devs do to fix the bugs will later have to be re-done to remove java dependence. The Steering Group and the Marketing Group don't have the leadership or skill to attract enough devs to avoid that duplication. No offence intended, it's a tough job. Regards from Tom :) --- On Thu, 15/9/11, Alexander Thurgood <[email protected]> wrote: From: Alexander Thurgood <[email protected]> Subject: [libreoffice-marketing] Re: Recruitment for Base (Was Re: [steering-discuss] Base - a new mailing list?) To: [email protected] Date: Thursday, 15 September, 2011, 11:38 Le 14/09/11 19:14, Robert Ryley a écrit : Hi Robert, > In order to market the package productively, some input from the base > developers would be helpful. I personally want to know > > 1. How integrated into writer, calc, etc. is base? > > 2. What exactly do we want base to do? Personally, if it isn't at > least somewhat compatible with MS access, I don't know what the point > is. I am not a developer, but I have been using the database stuff of OOo/LibO since before it even became open source, i.e. back in the day when it was still a proprietary StarDivision product - there has to my knowledge never been a specific remit for the database functionality to be Access compatible. It has always been more of a "offer the broadest general support for as many db engines as possible" kind of approach, and then this became a "provide a portable cross-platform single file db solution", in order for Sun to try and offer something akin to MS Access' own single file db solution. This is why although it is possible to use LibO to read from MS Access db files on Windows OS only, none of the reports, queries, forms etc that are available in a MS Access file are exploitable. There is currently no support for reading MS Access files on any other OS from within LibO that I know of (possibly with an ODBC driver one can read and write to Access files on Windows, but I wouldn't know). On Mac, it is possible to have read-only MS Access ODBC driver connections by paying for ActiveConnection's ODBC proprietary driver, but I haven't tried it. On Linux, reading mdb files and their schemata is up to the linux mdb drivers project, which are not integrated into LibO as far as I know. So the state of affairs with regard to actually using MS Access data for anything other than reading on platforms other than Windows is pretty grim. This has been a problem for more than 10 years. > > 3. To recruit developers, or at least make better use of current > volunteers, is there a willingness to explore/experiment with JVM > compatible languages that might speed up development time (after the > learning curve, of course)? The info gained from using base revisions > might help other areas of the project without being too disruptive to > other sections of the code. Also, working on something new and > "bleeding edge" would create some developer interest in communities > that wouldn't normally consider working on a "boring" office project. I could be wrong, but anything that involves more Java will probably not be immensely welcome in the project as the current trend is to try and remove as much of the Java dependencies as possible. > 5. There are a lot of smaller DB backends that could be used. MySQL > and Postgress aren't the only ones. SQLite is worthy of consideration > if it makes technical sense to scrap what is currently used. Someone had started on trying to integrate SQLite into the code as a replacement backend for hsqldb, but it appears that has stalled (or at least I can't seem to find anything in the current code base relating to that effort). It is currently built when compiling the mozilla nss integration required for digital signatures, but apparently there are known problems on some of the build systems (e.g. MacOS) because of conflicts between system libsqlite and the one that is required for the moz component. Alex -- Unsubscribe instructions: E-mail to [email protected] Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/marketing/ All messages sent to this list will be publicly archived and cannot be deleted -- Unsubscribe instructions: E-mail to [email protected] Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/marketing/ All messages sent to this list will be publicly archived and cannot be deleted
