Mark, this is how I think we got here. There is a compelling need to export engine semantics of UDFs and other types of plugins. The obvious -- and desireable way -- to do this is with abstract objects. Since there also needed some minor work on primary interface, it seemed logical to unite the primary and plugin engine interfaces in one abstract interface.
The original interface is also object oriented, but represents abstract objects with handles. In this interface, polymorphism (separation of abstraction and implementation) is performed by a y-valve that establishes an attachment to a provider and routes subsequent calls to that provider. A unified object oriented interface, unlike the original one, needs an intrinsic mechanism to implement the polymorphism required for the two instantiations. The way most object oriented languages do this is with a virtual method table. The problem is trying to make a virtual method table work well with multiple languages (which, in fact, boil down to C++ and Delphi, but there may be others). This is a daunting task. My position is that the external interface (the API) should remain y-valve and handle oriented, extended as needed. An interface for export engine semantics, however, has different requirements and can and should be encapsulated as a objections. There are two primary questions. The first is whether a common engine interface should be the same as the interface exported to plugins. The second question is what methodology should be used to encapsulate engine semantics for one or both of the interfaces. A secondary question is how to build language specific OO interfaces. The "two interface" camp holds that these are wrappers on the y-valve/handle interface. The "one interface" camp holds that these objects should be an instrinsic part of primary interface, and that y-valve/handle calls should be layered on these objects. Coloring the discussion further is differing philosophical views of where the project should go. One camp holds that the primary installed base is Delphi and that incompatible changes to the APIs is going to adversely affect this community. Another camp is to attract new users, Firebird should adopt and support a widely accepted industry standard like JDBC. Personally, I understand the appeal of a unified interface, but I don't see it as a requirement, and I do see adverse consequences to the project to all camps if it were adopted. In the meantime, a few developers have adopted the "damn the torpedoes, full speed ahead!" attitude towards criticism. I haven't a clue how this can be sorted out. > On Aug 12, 2014, at 5:55 AM, Mark Rotteveel <m...@lawinegevaar.nl> wrote: > > On Tue, 12 Aug 2014 13:18:31 +0400, Alex Peshkoff <peshk...@mail.ru> > wrote: >>> On Tue, 12 Aug 2014 10:37:21 +0400, Alex Peshkoff <peshk...@mail.ru> >>> wrote: >>>>> On 08/11/14 22:29, Tom Coleman wrote: >>>>> I interface a proprietary language with Firebird, Oracle, and >>>>> Sybase/MS-SQL. >>>>> >>>>> There is never any case where I would want to see std:exception. >>>>> >>>>> Could it be time to start thinking about burying this idea that is >>>>> looking more and more like a sacred cow? >>>> Tom if _you_ do not want to use one of the most powerful features of >>>> programming languages, please do not suggest others not to use it. >>> I think these types of response are not constructive and only serves to >>> alienate people. >> >> That was an answer to 'sacred cows'. > > Which is exactly why I said *these types* and not *this type*, the comment > applied to both. > >>> Please keep in mind that apart from the core developers, everyone here > is >>> discussing as an external consumer of this API. And unfortunate as that >>> may >>> be, an API for external consumption by disparate systems should cater > to >>> the lowest common denominator; and unfortunately that seems to be a C > API >>> (or in my case: the wire protocol *and* the C API). >>> >>> The fact that the Firebird core team prefers to use a C++ abstraction >>> inside Firebird is an entirely different discussion. By all means: use > a >>> C++ API internally, but external exposure of this API - unless a better >>> solution comes up (and I still haven't read the entire discussion so I >>> may >>> have missed something) - must be as simple as possible >> >> But that is exactly what we suggest... > > That is not how I read and interpret this discussion, and I get the > impression others have the same feeling. > >> Suggested approach makes it possible to automatically generate C API >> based on C++ API. This code will be certainly entirely C++ itself, but >> will make it possible to automatically expose part of new API as plain-C > >> functions. > > Auto-generation seems nice, but if done incorrectly leads to a hard to use > API or an unstable API because minor changes might escalate to unwanted or > unforeseen changes to said API. Also the *expose part of the API* seems to > suggest that it will deny users part of the API if they don't want to go > C++. > > I still get the feeling that a solution is chosen before the requirements > and needs are clear. > > Mark > > ------------------------------------------------------------------------------ > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
