Dmitry, these questions are a good starting point. To design (or select) an interface, you must start with a solid idea of who the users will be, their skill level, how they will use it, and where you want to go with the product.
For example, the original interface targeted two classes of usage: Language preprocessors and 4GLs (e.g. Datatrieve). It was never intended that any application level program would ever use the API directly. Later, it was used for the dynamic SQL layer that is now the primary interface (again, I apologize for the really crappy DSQL interface -- I picked an existing interface with a pure heart but bad taste). Right now, the Firebird project is clearly split between those who want to server the installed base (Delphi mostly) and those who want to attract significant number of new users. Until there is some agreement here there is very little purpose to even discussing an interface. I know that there are many who will disagree strongly, but in my opinion Delphi is a dead end, one of many worthy languages that didn't prevail like Algol-60, PL/I, Lisp, and Bliss. Support Delphi users, by all means, but they neither need nor want a new interface. Extensions, sure, but something new and different for a dying language and declining base, I don't think so. There is no reason that the primary interface needs to be programmer friendly as long as language specific wrappers are easy and cheap to write and incur almost no overhead. So you can think of the real API as assembler used by higher level languages. The best way to study interfaces is to first implement them as a proper layer on the existing interface. This allows cheap implementation and fast iteration. When the interface matures, move it into the y-valve and eventually into the protocol. And once I again I urge Firebird to adopt a modern, industry standard, widely accepted SQL interface. There is really only one candidate, which is JDBC. Finally, take the big issues first. If you don't know where the project is going, what is the point of fighting over quasi-language independent erzatz vtables? Decide where you want to go then figure out how to get there and design (or select!!!!) an interface accordingly. > On Aug 10, 2014, at 9:02 AM, Dmitry Yemanov <firebi...@yandex.ru> wrote: > > 10.08.2014 14:10, Jim Starkey wrote: > >> It is a fool's errand to try to build a OO interface that is call compatible >> across a wide range of OO languages. If anyone is in doubt, look at >> Objective-C and weep. > > If this is found being impossible (I'm not deeply involved, so I don't > have a strongly argumented opinion yet), then we have [at least] three > questions to answer: > > 1) Do we keep the existing OO Y-valve API for internal purposes? E.g. > for engine plugins or for remote->engine calls. The same issues apply > but we can expect virtually zero practical risks here (I doubt we'll be > writing some parts of the server in FreePacal or Lua). Maybe some > interfaces could be simplified in this case. > > 2) Do we offer the existing OO Y-valve API to other C++ users? It has to > be public and limitations (including binding issues) have to be documented. > > 3) Do we keep using the legacy ISC API as the "plain C" wrapper for > non-C++ users or invent a better replacement? > > > Dmitry > > > ------------------------------------------------------------------------------ > 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
