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
