On 24/03/2016 13:01, Jim Starkey wrote: > 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),
Stored objects are submitted in BLR. > BLR > objects were shared across connections (planned but never implemented), Could be. > user requests are virtually > always in SQL, They are not. Stored objects are already in BLR. > prepared requests are not shared Could be. > > 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. > Again, it's the same thing of any compiled language. You want to compile sources on demand. Adriano ------------------------------------------------------------------------------ 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
