Firebird as backend in LibreOffice.

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Firebird as backend in LibreOffice.

MiguelAngel
Hi,

I have not seen in Firebird web any comment about the intention in LibreOffice for use Firebird as backend.

https://wiki.documentfoundation.org/Development/GSoC/Ideas#Support_for_Firebird_Database_in_Base

https://bugs.freedesktop.org/show_bug.cgi?id=51780

I am user of Firebird and LibreOffice, in the LibreOffice project collaborating with QA and helping users in ask.libreoffice.org.

I like very much the idea of Firebird as backen for LibreOffice, what I think can be in profit for both communities.

Maybe someone from Firebird side can help in to achieve the right implementation for LibreOffice, what is being asked on both links.

I was redirect to this list from
[hidden email].

Thanks so much for this great project.

Regards.

Miguel Ángel Ríos.
A Coruña - Spain.


------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and
their applications. This 200-page book is written by three acclaimed
leaders in the field. The early access version is available now.
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Reply | Threaded
Open this post in threaded view
|

Re: Firebird as backend in LibreOffice.

Vlad Khorsun-2
> I have not seen in Firebird web any comment about the intention in LibreOffice for use Firebird as backend.
>
> https://wiki.documentfoundation.org/Development/GSoC/Ideas#Support_for_Firebird_Database_in_Base
>
> https://bugs.freedesktop.org/show_bug.cgi?id=51780
>
> I am user of Firebird and LibreOffice, in the LibreOffice project collaborating with QA and helping users in ask.libreoffice.org.
>
> I like very much the idea of Firebird as backen for LibreOffice, what I think can be in profit for both communities.

    Why not ? :)

> Maybe someone from Firebird side can help in to achieve the right implementation for LibreOffice, what is being asked on both
> links.

    Of course we can help with Firebird side of things. Could you point us to the concrete issue\question ?

So far i see two open questions raised at links above:

a) Can we just ship it in LIBROFFICE_ROOT/program/fbserver? Or will it want config files in /etc/ and that kind of things?

    Since Firebird 2.5 you could place embedded kit at any place you like, just point FIREBIRD environment variable to
this folder. As for config files and other misc items - see

    http://www.firebirdsql.org/file/documentation/release_notes/html/rlsnotes252.html#rnfb25-install-lin-configure


b) can we redirect FireBird's read()/write() to our internal data structures in this scenario? This could be a blocking issue

    You can look at PIO_read\PIO_write and company and modify them to redirect database IO into your file.
But i would not recommend to do it.

Regards,
Vlad


------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and
their applications. This 200-page book is written by three acclaimed
leaders in the field. The early access version is available now.
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Reply | Threaded
Open this post in threaded view
|

Firebird as backend in LibreOffice.

MiguelAngel
Hi Vlad,
thanks for your detailed and quick answer.
I'll comment when I have news.
Regards.
Miguel Ángel

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Reply | Threaded
Open this post in threaded view
|

Re: Firebird as backend in LibreOffice.

Andres Gomez
In reply to this post by Vlad Khorsun-2
Hi,

a workmate of me and I have started to work on the creation of a SDBC
driver for LibreOffice (LibO) based in Firebird. In the long run, the
intention is to replace the default HSQLDB driver in LibO.

This is our first experience with Firebird, although I used the old
Interbase versions from Delphi and C++ Builder, but that was a long long
time ago, through Borland's APIs and in a Windows environment.

Right now, our main development environment is Linux. We will face the
other platforms once we have something working.

Therefore, we would appreciate guidance in this task. I'm writing some
doubts/problems that we are facing currently.

 * FB2.5 vs FB3:
   * Implementation of the SDBC driver in LibO will take time. We have
read that FB3 release should be soon. There is actually already an
"Alpha 1" version so we are wondering which version we should be using
in our development. Having an estimation of the FB3 stable release would
be helpful.
   * We understand that FB3 will be backward compatible in its API with
FB2.5 but that it will also bring a new C++ API. LibO is written vastly
in C++ and having an OO API would be very handy for our development.
Here we have several options and we would need advice to chose the best
approach:
     - Use the plain C API, knowing that it will be fully compatible
with FB2.5 or FB3.
     - Use an external C++ API, like IBPP. IBPP is a tested and quite
old wrapper over FB's C API but we wonder how well maintained it is as
latest stable release is from 2007. We understand that, although usable,
it would be better to have something that will have a brighter future.
In addition, this adds another external dependency to LibO.
      - Use the new internal C++ API. I assume this leaves us only with
the option of going for FB3. Maybe would it be possible to isolate and
compile the new C++ API against FB2.5 too?
   * Firebird embedded: LibO needs to use the embedded version of FB for
its planned SDBC driver. fbembed is available in FB2.5. However,
compiling FB3 in Linux doesn't generate the library nor we have found
any "configure" switch for it. In addition, we have not been able to
find it in FB3 nightly builds for Windows nor for Linux. Has fbembed
been dropped? Is there any important change that has been done not to
have it any more of is it that it can be generated/used in some other
way?

 * ICU: FB brings its own version of the ICU library embedded. Fedora
and Debian projects compile their FB packages against their system's
libicu. However, both distributions provide warning notices saying that
incompatibilities can happen in the usage of the generated databases
indexes among FB servers which use different versions of the ICU
library. Is this correct? Can we assume, then, that for keeping a broad
compatibility in different compilations and versions of LibO we will
have to compile FB and its bundled libicu always internally and not to
use a possible version existing in the system?

 * MacOS support: while we see that FB packages are available for
Windows and Linux, we also have noticed that the releases of MacOS
binaries doesn't happen that often. Actually, there are no MacOS nightly
builds for FB3. We are worried that this could mean that MacOS
compilation could be problematic. LibO targets several platforms
including MacOS so help on MacOS compilation would be welcomed. We would
also be sure that it won't be a problem in the future.

* Lack of up to date development documentation, specially for fbembed:
one of the biggest problems that we are facing is that the freely
available documentation for developers is scarce and quite old.
Specifically, there is not much documentation in relation with fbembed
on Linux. In this link:
http://www.firebirdsql.org/manual/ufb-cs-embedded.html#ufb-cs-embedded-linux

It is said:
"
...
Finally, you can't just ship libfbembed.so with your application and use
it to connect to local databases. Under Linux, you always need a
properly installed server, be it Classic or Super.
"

We understand this was needed due to the usage of "fb_lock_mgr". We have
seen that the lock manager binary was dropped in later FB versions and,
at least, it is not needed in FB2.5. Therefore, we understand that
currently fbembed is a true embedded server also for Linux/MacOS and
there is no need of a local server installation any more. Is this
correct?

In addition, following all the documentation we have found so far about
"fbembed" usage, we see that other files have to be shipped with the
library:
 * libfbembed.so
 * libib_util.so
 * libicudata.so
 * libicui18n.so
 * libicuuc.so
 * firebird.conf
 * firebird.msg
 * intl/fbintl
 * intl/fbintl.conf
 * udf/fbudf.so

Is this correct? All these files have to be shipped? Are there
differences among Windows, Linux and MacOS?

---

Apologies for the lenght of the mail. Also, if this is not the correct
mailing list/forum in which to ask these questions. We will be happy if
anyone can address us to the proper place, then.

Thanks in advance for your help.

Br.
--
Andres Gomez
Computer Science Engineer
mailto:[hidden email]
http://blogs.igalia.com/agomez/category/igaliacom/
IGALIA, S.L. http://www.igalia.com


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Reply | Threaded
Open this post in threaded view
|

Re: Firebird as backend in LibreOffice.

Alex Peshkoff
On 05/27/13 15:30, Andres Gomez wrote:

> Hi,
>
> a workmate of me and I have started to work on the creation of a SDBC
> driver for LibreOffice (LibO) based in Firebird. In the long run, the
> intention is to replace the default HSQLDB driver in LibO.
>
> This is our first experience with Firebird, although I used the old
> Interbase versions from Delphi and C++ Builder, but that was a long long
> time ago, through Borland's APIs and in a Windows environment.
>
> Right now, our main development environment is Linux. We will face the
> other platforms once we have something working.
>
> Therefore, we would appreciate guidance in this task. I'm writing some
> doubts/problems that we are facing currently.
>
>   * FB2.5 vs FB3:
>     * Implementation of the SDBC driver in LibO will take time. We have
> read that FB3 release should be soon. There is actually already an
> "Alpha 1" version so we are wondering which version we should be using
> in our development. Having an estimation of the FB3 stable release would
> be helpful.

At least one year. That's major release, and too many things were changed.

>     * We understand that FB3 will be backward compatible in its API with
> FB2.5 but that it will also bring a new C++ API. LibO is written vastly
> in C++ and having an OO API would be very handy for our development.
> Here we have several options and we would need advice to chose the best
> approach:
>       - Use the plain C API, knowing that it will be fully compatible
> with FB2.5 or FB3.
>       - Use an external C++ API, like IBPP. IBPP is a tested and quite
> old wrapper over FB's C API but we wonder how well maintained it is as
> latest stable release is from 2007.

Plain C API almost did not change for a very long time, May be that's
reason that well-working C++ helper for it does not need maintenance.

> We understand that, although usable,
> it would be better to have something that will have a brighter future.
> In addition, this adds another external dependency to LibO.
>        - Use the new internal C++ API. I assume this leaves us only with
> the option of going for FB3. Maybe would it be possible to isolate and
> compile the new C++ API against FB2.5 too?

Yes. It's possible though not trivial. But must say that we were anyway
thinking about it - to amke it possible to use 2.5 embedded library as
an FB3 provider.

>     * Firebird embedded: LibO needs to use the embedded version of FB for
> its planned SDBC driver. fbembed is available in FB2.5. However,
> compiling FB3 in Linux doesn't generate the library nor we have found
> any "configure" switch for it. In addition, we have not been able to
> find it in FB3 nightly builds for Windows nor for Linux. Has fbembed
> been dropped? Is there any important change that has been done not to
> have it any more of is it that it can be generated/used in some other
> way?

Yes, that change is providers architecture. We do not need separate
embedded library any more cause fbclient can load DB engine (it is
plugins/libengine12.so) and act as embedded. And this is exactly how FB3
server normally works.

>
>   * ICU: FB brings its own version of the ICU library embedded. Fedora
> and Debian projects compile their FB packages against their system's
> libicu. However, both distributions provide warning notices saying that
> incompatibilities can happen in the usage of the generated databases
> indexes among FB servers which use different versions of the ICU
> library. Is this correct? Can we assume, then, that for keeping a broad
> compatibility in different compilations and versions of LibO we will
> have to compile FB and its bundled libicu always internally and not to
> use a possible version existing in the system?

Yes, seems to be so. And for FB3 you should take special care to make
firebird use exactly this ICU version - by default it's using system one.

>
>   * MacOS support: while we see that FB packages are available for
> Windows and Linux, we also have noticed that the releases of MacOS
> binaries doesn't happen that often. Actually, there are no MacOS nightly
> builds for FB3. We are worried that this could mean that MacOS
> compilation could be problematic. LibO targets several platforms
> including MacOS so help on MacOS compilation would be welcomed. We would
> also be sure that it won't be a problem in the future.

We support Mac as our third regular platform, but for some technical
reasons (like missing enough Mac boxes) releases are delayed sometimes
compared with linux & windows. Typically not more than for 2 weeks. And
yes, we plan to support Mac in the future.

>
> * Lack of up to date development documentation, specially for fbembed:
> one of the biggest problems that we are facing is that the freely
> available documentation for developers is scarce and quite old.

What about C API - probably best source is still ib6.0 beta docs from
Borland. For C++ API I plan to have some good samples with a lot of
comments as documentation, but it is not ready yet.

> Specifically, there is not much documentation in relation with fbembed
> on Linux. In this link:
> http://www.firebirdsql.org/manual/ufb-cs-embedded.html#ufb-cs-embedded-linux
>
> It is said:
> "
> ...
> Finally, you can't just ship libfbembed.so with your application and use
> it to connect to local databases. Under Linux, you always need a
> properly installed server, be it Classic or Super.
> "
>
> We understand this was needed due to the usage of "fb_lock_mgr". We have
> seen that the lock manager binary was dropped in later FB versions and,
> at least, it is not needed in FB2.5. Therefore, we understand that
> currently fbembed is a true embedded server also for Linux/MacOS and
> there is no need of a local server installation any more. Is this
> correct?

The main problem with embedded access is that everyone who needs it
should share (except databases themself) additional shared memory
structures with others. And this requires some box tuning to work well.
Such tuning is done when installing server. If in your case ebmedded
access is supposed to be used only to _own_ files (hmm, looks like
office software typically works this way?) than this can be relatively
easy solved setting some env var-s before first firebird call.

> In addition, following all the documentation we have found so far about
> "fbembed" usage, we see that other files have to be shipped with the
> library:
>   * libfbembed.so
yes for 2.5
for 3 - libfbclient and plugins/libengine12
>   * libib_util.so
this is UDFs support
if you plan to let people use UDFs returning strings - this library is
required
>   * libicudata.so
>   * libicui18n.so
>   * libicuuc.so
that's all we need from ICU
>   * firebird.conf
main config file
since fb3 not required for embedded access
>   * firebird.msg
messages
better have them
btw, this is a place where messages from FB may be internationalized
>   * intl/fbintl
>   * intl/fbintl.conf
both required to support intl charsets
>   * udf/fbudf.so

sample UDFs
not required

> Is this correct? All these files have to be shipped? Are there
> differences among Windows, Linux and MacOS?
>

Right now I do not see much differences.
Certainly, default layouts sligtly differ.


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Reply | Threaded
Open this post in threaded view
|

Re: Firebird as backend in LibreOffice.

Javier Fernandez
Hi Alex,

Thanks for your reply.

On 27/05/13 17:20, Alex Peshkoff wrote:

> On 05/27/13 15:30, Andres Gomez wrote:
>>     * We understand that FB3 will be backward compatible in its API with
>> FB2.5 but that it will also bring a new C++ API. LibO is written vastly
>> in C++ and having an OO API would be very handy for our development.
>> Here we have several options and we would need advice to chose the best
>> approach:
>>       - Use the plain C API, knowing that it will be fully compatible
>> with FB2.5 or FB3.
>>       - Use an external C++ API, like IBPP. IBPP is a tested and quite
>> old wrapper over FB's C API but we wonder how well maintained it is as
>> latest stable release is from 2007.
>
> Plain C API almost did not change for a very long time, May be that's
> reason that well-working C++ helper for it does not need maintenance.

Yes, we are still considering the use of the IBPP helper for the
implementation, but so far, the C API works fine. Since the Driver is
not too complex for the time being, targeting just the embedded
approach, avoiding a new layer seems reasonable.

Perhaps the best approach would be to wait for the release of the FB3
API to port the Driver to a pure C++ implementation.

>
>> We understand that, although usable,
>> it would be better to have something that will have a brighter future.
>> In addition, this adds another external dependency to LibO.
>>        - Use the new internal C++ API. I assume this leaves us only with
>> the option of going for FB3. Maybe would it be possible to isolate and
>> compile the new C++ API against FB2.5 too?
>
> Yes. It's possible though not trivial. But must say that we were anyway
> thinking about it - to amke it possible to use 2.5 embedded library as
> an FB3 provider.

That would be an interesting option. I would be interested on knowing
more details about how to do it.

Br.

------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Reply | Threaded
Open this post in threaded view
|

Re: Firebird as backend in LibreOffice.

Alex Peshkoff
On 06/04/13 14:40, Javier Fernandez wrote:

> Hi Alex,
>
> Thanks for your reply.
>
> On 27/05/13 17:20, Alex Peshkoff wrote:
>> On 05/27/13 15:30, Andres Gomez wrote:
>>>      * We understand that FB3 will be backward compatible in its API with
>>> FB2.5 but that it will also bring a new C++ API. LibO is written vastly
>>> in C++ and having an OO API would be very handy for our development.
>>> Here we have several options and we would need advice to chose the best
>>> approach:
>>>        - Use the plain C API, knowing that it will be fully compatible
>>> with FB2.5 or FB3.
>>>        - Use an external C++ API, like IBPP. IBPP is a tested and quite
>>> old wrapper over FB's C API but we wonder how well maintained it is as
>>> latest stable release is from 2007.
>> Plain C API almost did not change for a very long time, May be that's
>> reason that well-working C++ helper for it does not need maintenance.
> Yes, we are still considering the use of the IBPP helper for the
> implementation, but so far, the C API works fine. Since the Driver is
> not too complex for the time being, targeting just the embedded
> approach,

As soon as embedded driver exists it will work for remote connections
too. Even login/password may be specified in env.

> avoiding a new layer seems reasonable.
>
> Perhaps the best approach would be to wait for the release of the FB3
> API to port the Driver to a pure C++ implementation.

Yes, the only minus is time needed for release or need to write a 2.5
provider (see later).

>>> We understand that, although usable,
>>> it would be better to have something that will have a brighter future.
>>> In addition, this adds another external dependency to LibO.
>>>         - Use the new internal C++ API. I assume this leaves us only with
>>> the option of going for FB3. Maybe would it be possible to isolate and
>>> compile the new C++ API against FB2.5 too?
>> Yes. It's possible though not trivial. But must say that we were anyway
>> thinking about it - to amke it possible to use 2.5 embedded library as
>> an FB3 provider.
> That would be an interesting option. I would be interested on knowing
> more details about how to do it.
>

Firebird provider must be written. Ability to write own providers was
one of the goals of FB3, and there are some things done to help with
this task, but ... that all is not really tested.

In brief - one should implement about 10 interfaces with approx 50-60
virtual functions in all of them. Implementation in most cases is
trivial - just call appropriate plain C function, in others - a bit more
complicated. Second case takes place when there is no 1to1 relationship
between old and new interfaces. On the other hand most of classes,
needed to connect old/new API, already exist in FB src tree. They were
needed to provide compatibility between new client and old server.

But I'm afraid that devil (as always) hides in the details. As a minimum
there may be problems at shutdown time - unloading library that creates
threads itself is rather interesting task. Different threads management
between 2.5 & 3 is another possible source of problems. Not to say they
are unsolvable, but I do not expect such provider to start to work too
easily.


------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel