On 3/24/2016 10:50 AM, Adriano dos Santos Fernandes wrote: >> Creating a new BLR version number doesn't make sense since >> it is hoped that future versions of Firebird will treat BLR as at most a >> legacy interface. >> > So you suggest Java .class go away? Compile source code dynamically and run? > > Same for C++? No binary anymore? > >
If user requests were submitted in BLR (which they once were), BLR objects were shared across connections (planned but never implemented), and modern computers where slow an memory starved, you would have a sound argument. But none of these conditions are met. System requests are prepared once per server activation, user requests are virtually always in SQL, prepared requests are not shared, and $400 computer have 8,000 times the max memory of the machines on which I created Interbase. The 1980s are gone, Adriano, deal with it. BLR is an obsolete artifact from a different era. It makes no engineering sense. It adds complexity and subtracts performance. It is a hindrance to adding new features. It serves no purpose other than legacy support for backwards compatibility. It would be cheaper and better to eliminate than to extend. ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140 Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
