As an outsider looking in, I think I understand how you got there but not the "there" you got.
For openers, I don't understand what a plugin architecture has to do with the primary database API. They are different beasts used for different purposes by different types of developers. The demands on a general plugin API are really quite different (frankly, I'd be inclined to use COM and query interface for plugins). I also don't understand why you want to make the interface OO. First, you seem content with a tiny client base (Delphi) that has been using a stable interface for what, a couple of decades? Why are they going to want (or benefit) from a completely different interface that is neither industry standard or significantly more functional than the existing interface. The y-valve architecture is designed from the git-go to hide the implementation from the interface. It may not be the technology of choice if you were starting with modern languages that didn't exist when it was designed, but it has stood up quite well and is clearly and cleanly extensible (which is why it stood up so well). Why do you think you need a incompatible interface that uses a different (and weaker) mechanism to hide the implementation? What problem are you trying to solve here? I can understand extending the existing interface with new calls for new functionality (e.g. 32 bit object sizes). This is so trivial it's boring. I can also understand adding an incompatible but industry standard interface if you were interested in expanding the Firebird audience (but what you are, sadly, not). But for the life of me, I can't understand why you are defining an incompatble interface that is useful neither for the installed base or to extend that base. So, if I understand your original goals, again as an outsider, I would have to say that your current interface proposal does not meet them. Each step in the progression may have seen logical, but the end result is not. > On Aug 8, 2014, at 8:20 AM, Alex Peshkoff <peshk...@mail.ru> wrote: > >> On 08/07/14 21:25, Jim Starkey wrote: >> Just as a matter of curiosity, is there an agreed on set of requirements for >> the new interface? If not, may I suggest that one be drawn up and >> discussed? It's very hard to measure the success of a design without >> knowing what it is supposed to do. > > There were (except others) 3 goals when starting with FB3 - establish > plugins architecture, reanimate providers architecture and avoid 16-bit > limit on object sizes in API calls. > > Initially an interface for plugins was suggested. It was decided (nobody > argued against, therefore we need not prepare strong arguments) to have > OO interface for it. With one strong desire - when some new method is > missing in old plugin user is reported an error, but old functionality > of plugin may still be used. Certainly explicit version check is > possible, but a method used in yvalve (replacing missing calls with a > stub returning isc_wish_list) looked better - we need not waste time on > checks in every call. Here I've made a mistake - after reading some old > MSDN I was pretty sure that all C++ compilers create VT in same form, it > was around 1998-2000 explicitly documented in OLE2 description with a > sample of accessing that tables from plain C program. I've too much > trusted old MS doc. Well, in available compilers that worked and time > came for providers. > > Already having a code for loading, runtime maintenance around, > unloading, etc. for plugins it was rather logical to treat provider as a > plugin and build interface for it as for any other plugin, i.e. OO. That > moment I did not plan to use it as public database API. So the choice of > API as close to ISC API was first of all to simplify yvalve. (Result set > separate from statement, interface for messages description arrived > later.) That all certainly worked - and it was done with 32-bit object > sizes. I really do not remember who's idea was to use it as a base for > public API supporting 32-bit objects, but once again nobody of > developers argued again. And with some enhancements designed to replace > SQLDA for data access - well, it looks for us better than ISC API. > > So you see - there were not initial requirements. Looks like we somewhat > followed interbase traditions in this aspect :) > > Currently we have a desire to make API on the one hand > compiler-independent, on the other - when used in C++ make more '++', > i.e. have automatic Exception <=> StatusVector conversions. > > > ------------------------------------------------------------------------------ > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
