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
