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).


Dmitry


------------------------------------------------------------------------------
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Reply via email to