Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


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 <alex.thurgood@gmail.com> wrote:

From: Alexander Thurgood <alex.thurgood@gmail.com>
Subject: [libreoffice-marketing] Re: Recruitment for Base (Was Re: [steering-discuss] Base - a new 
mailing list?)
To: marketing@global.libreoffice.org
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 marketing+help@global.libreoffice.org
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 marketing+help@global.libreoffice.org
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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.