|
Hi! Some note from an outsider view. #1 : both client & plugin API MUST support C-tyle API (lowest common dominator) - standard data types, zero terminated strings, pointers/handles, records, stdcall/cdecl functions, NO objects/interfaces - most of the API developers will and can only use this. (if will be not supported most of the user base will be lost) #2 : old client API should not be changed at all - why the new API if old one is also developed? - backward compatibility #3 : client & plugin OO API - only C++ developers can use is (small part of the whole user base pie) - not just the different Object memory layout is the problem, but the different memory managers also. Object can be shared via API just in case of same compiler with same memory optimization settings AND shared memory manager. - why maintain a second one API? Can gain siginficant performance over C style API? What are the cons? #4 : new API should be designed from scratch, in mind of : - eliminate/expand current limits - better multithread scalability - make place for future FB developements - make place for supporting missing SQL standard features -- Molnár Attila szoftverfejlesztő Tel : 372-3333 E-mail: amol...@mve.hu LIBRA Szoftver zrt. 1113 Bp. Karolina út 65. Tel: 372-3333 Fax: 209-1477 Web: www.mve.hu E-mail: i...@mve.hu Olvasson ügyfeleinkkel elért közös sikereinkről: http://www.mve.hu/hu/referenciaink |
------------------------------------------------------------------------------
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
