[libreoffice-marketing] Re: Recruitment for Base (Was Re: [steering-discuss] Base - a new mailing list?)

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