On 08/11/14 15:00, Dmitry Yemanov wrote: > 11.08.2014 13:45, Mark Rotteveel wrote: > >> To illustrate: you seem (?) to be speaking from the perspective of a >> target audience who use the interface in application development, and where >> you don't want to deal with all the nitty gritty low-level details, here >> IBPP is probably a good fit (but as I haven't used it, I can't say). >> >> However speaking as the developer of Jaybird, I don't want an API that >> will perform too many conversions or work that I will need to redo to make >> it work the same or similar as the wire protocol implementation, and to >> make it work within the rules established by JDBC. In that case an API that >> does too much heavy lifting is actually a hindrance (or at minimum a >> potential performance bottleneck). >> >> These are already two - somewhat - conflicting needs. Personally I'd say >> that Firebird should at minimum have a low-level API (which the current >> ibase.h provides, although it has some annoyances). A higher level API >> (like IBPP) to do some of the heavy lifting for application development is >> a nice to have. And as you say: it already exists: IBPP. > This is exactly the developer's position, at least how I understand it > myself ;-) IBPP is C++ only and too high-level. The FB API should be > lower-level and language-independent. The legacy ISC API mostly serves > this goal (although it's not that low-level really, some hidden > conversions/movements happen there), but it's showing its age. So we > attempted to offer a modern replacement with the v3 OO API. IBPP can > still act as a high-level C++ wrapper, FIBPlus/FireDAC/whatever would > act the same for Delphi, etc. They just need to be ported to the new > core API (whatever it will be).
I agree with this is POV 100%. ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
