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
